name: Label Approved

on:
  schedule:
    - cron: "0 12 * * *"
  workflow_dispatch:

permissions:
  pull-requests: write

jobs:
  label-approved:
    if: github.repository_owner == 'fastapi'
    runs-on: ubuntu-latest
    steps:
    - name: Dump GitHub context
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: echo "$GITHUB_CONTEXT"
    - uses: actions/checkout@v6
    - name: Set up Python

Once a native speaker comes, reviews the PR, and approves it, the GitHub Action will come and remove the `awaiting-review` label, and add the `approved-1` label.

This way, we can notice when there are new translations ready, because they have the `approved-1` label.

## Merge Translation PRs

Translations are generated automatically with LLMs and scripts.

			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>
		<Logger name="org.dbflute" additivity="false" level="${log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>
		<Logger name="org.lastaflute" additivity="false" level="${log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>

from pydantic import BaseModel, SecretStr
from pydantic_settings import BaseSettings


class LabelSettings(BaseModel):
    await_label: str | None = None
    number: int


default_config = {"approved-2": LabelSettings(await_label="awaiting-review", number=2)}


class Settings(BaseSettings):
    github_repository: str
    token: SecretStr
    debug: bool | None = False

			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>
		<Logger name="org.dbflute" additivity="false" level="${log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>
		<Logger name="org.lastaflute" additivity="false" level="${log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>

	</Appenders>

	<Loggers>
		<Logger name="org.codelibs.fess" additivity="false" level="${log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>
		<Root level="${root.log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Root>
	</Loggers>

	</Appenders>

	<Loggers>
		<Logger name="org.codelibs.fess" additivity="false" level="${log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Logger>
		<Root level="${root.log.level}">
			<AppenderRef ref="AppFile" />
			<AppenderRef ref="LogNotification" />
		</Root>
	</Loggers>

errors.failed_to_download_elevate_file = Impossibile scaricare il file delle parole elevate.
errors.failed_to_upload_elevate_file = Impossibile caricare il file delle parole elevate.
errors.failed_to_download_badword_file = Impossibile scaricare il file delle parole proibite.
errors.failed_to_upload_badword_file = Impossibile caricare il file delle parole proibite.
errors.failed_to_download_mapping_file = Impossibile scaricare il file di mappatura.

* **Starlette** :
    * A les secondes meilleures performances après Uvicorn. En réalité, Starlette utilise Uvicorn. De ce fait, il ne peut qu’être plus « lent » qu'Uvicorn car il requiert l'exécution de plus de code.
    * Cependant, il apporte les outils pour construire une application web simple, avec un routage basé sur des chemins, etc.
    * Si on compare Starlette, il faut le comparer à d'autres frameworks web (ou microframeworks) comme Sanic, Flask, Django, etc.

Vous pouvez déclarer qu'une variable peut être **plusieurs types**, par exemple, un `int` ou un `str`.

Pour le définir, vous utilisez la <dfn title='aussi appelé « opérateur OU bit à bit », mais ce sens n’est pas pertinent ici'>barre verticale (`|`)</dfn> pour séparer les deux types.

C'est ce qu'on appelle une « union », car la variable peut être n'importe quoi dans l'union de ces deux ensembles de types.

```Python hl_lines="1"