Traduction de la documentation Kubernetes
La documentation de Kubernetes est disponible dans plusieurs langues. Nous vous encourageons à ajouter de nouvelles traductions!
Commencer
Les traductions doivent avoir certains pré-requis pour le workflow (comment traduire) et la sortie (quoi traduire) avant de publier.
Pour ajouter une nouvelle localisation de la documentation de Kubernetes, vous devrez mettre à jour le site web en modifiant le paramètre site configuration et directory structure. Alors vous pouvez commencer la traduction de documents!
Indiquez à Kubernetes SIG Docs que vous souhaitez créer une traduction! Rejoignez le canal Slack SIG Docs. Nous sommes heureux de vous aider à démarrer et à répondre à toutes vos questions.
Toutes les équipes de traduction doivent être autonomes avec leurs propres ressources. Nous sommes heureux d'accueillir votre travail, mais nous ne pouvons pas le traduire pour vous.
Fork et cloner le dépôt
D'abord, créez votre fork du dépôt kubernetes/website.
Ensuite, clonez ce dépôt et mettez vous dedans (avec une commande cd):
git clone https://github.com/kubernetes/website
cd website
Les contributeurs de k/website doivent créer un fork à partir duquel les pull requests seront ouvertes.
Pour les localisations, nous demandons en outre que :
- Les approbateurs d'équipe ouvrent des branches de développement directement à partir de https://github.com/kubernetes/website.
- Les contributeurs à la localisation travaillent à partir de forks, avec des branches basées sur la branche de développement actuelle.
Cela s'explique par le fait que les projets de localisation sont des efforts de collaboration sur des branches à long terme, similaires aux branches de développement pour le cycle de release de Kubernetes. Pour plus d'informations sur les pull request de localisation, voir "branching strategy".
Trouvez votre code de langue à deux lettres
Consultez la norme ISO 639-1 pour le code de pays en deux lettres de votre localisation.
Par exemple, le code à deux lettres pour l'allemand est de.
de) as an example.
Modifier la configuration du site
Le site web de Kubernetes utilise Hugo comme son web framework.
La configuration Hugo du site Web se trouve dans le fichier config.toml.
Pour prendre en charge une nouvelle localisation, vous devrez modifier config.toml.
Ajoutez un bloc de configuration pour la nouvelle langue dans config.toml, sous le bloc [languages] existant.
Le bloc allemand, par exemple, ressemble à :
[languages.de]
title = "Kubernetes"
description = "Produktionsreife Container-Verwaltung"
languageName = "Deutsch"
contentDir = "content/de"
weight = 3
Lors de l'attribution d'un paramètre de weight à votre bloc, trouvez le bloc de langue ayant le weight le plus élevé et ajoutez 1 à cette valeur.
Pour plus d'informations sur le support multilingue de Hugo, voir "Multilingual Mode".
Ajouter un nouveau répertoire de localisation
Ajoutez un sous-répertoire spécifique à la langue dans le répertoire content du dépôt.
Par exemple, le code à deux lettres pour l'allemand est "de" :
mkdir content/de
Ajouter un README localisé
Pour guider les autres contributeurs à la localisation, ajoutez un nouveau README-**.md au plus haut niveau de k/website, où ** est le code de langue à deux lettres.
Par exemple, un fichier README allemand serait README-de.md.
Fournir des conseils aux contributeurs à la localisation dans le fichier localisé README-**.md.
Incluez les mêmes informations que celles contenues dans README.mdainsi que :
- Un point de contact pour le projet de localisation
- Toute information spécifique à la localisation
Après avoir créé le fichier README localisé, ajoutez un lien vers le fichier à partir du fichier anglais principal, [README.md's Localizing Kubernetes Documentation] et incluez les coordonnées des personnes-ressources en anglais.
Vous pouvez fournir un identifiant GitHub, une adresse e-mail, Slack channel, ou toute autre méthode de contact.
Translating documents
Localiser toute la documentation de Kubernetes est une tâche énorme. Il n'y a pas de mal à commencer petit et progresser avec le temps.
Au minimum, toutes les localisations doivent inclure :
| Description | URLs |
|---|---|
| Home | All heading and subheading URLs |
| Setup | All heading and subheading URLs |
| Tutorials | Kubernetes Basics, Hello Minikube |
| Site strings | All site strings in a new localized TOML file |
Les documents traduits doivent résider dans leur propre sous-répertoire content/**/, mais sinon suivre le même chemin URL que la source anglaise.
Par exemple, pour préparer le tutoriel Kubernetes Basics à traduire en allemand, créez un sous-dossier sous le dossier `content/de/' et copiez la source anglaise :
mkdir -p content/de/docs/tutorials
cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md
Pour un exemple de demande liée à la localisation pull request, this pull request au Kubernetes website repo a ajouté la localisation coréenne aux documents Kubernetes.
Fichiers sources
Les localisations doivent utiliser les fichiers anglais de la version la plus récente comme source. La version la plus récente est v1.23.
Pour trouver les fichiers sources de la version la plus récente :
- Accédez au dépôt du site web de Kubernetes à l'adresse suivante https://github.com/kubernetes/website.
- Sélectionnez la branche `release-1.X' pour la version la plus récente.
La dernière version est v1.23, donc la branche de la release la plus récente est release-1.23.
Chaînes de sites en i18n/
Les localisations doivent inclure le contenu des éléments suivants i18n/en.toml dans un nouveau fichier spécifique à la langue.
Prenons l'allemand comme exemple : i18n/de.toml.
Ajouter un nouveau fichier de localisation dans i18n/. Par exemple, avec l'allemand (de) :
cp i18n/en.toml i18n/de.toml
Traduisez ensuite la valeur de chaque chaîne de caractères :
[docs_label_i_am]
other = "ICH BIN..."
La localisation des chaînes de caractères du site vous permet de personnaliser le texte et les fonctionnalités du site : par exemple, le texte du copyright légal dans le pied de page de chaque page.
Logistique de projet
Contactez les responsables du SIG Docs
Contactez l'un des présidents du Kubernetes SIG Docs lorsque vous démarrez une nouvelle localisation.
Mainteneurs
Chaque traduction doit fournir ses propres responsables. Les responsables peuvent appartenir à une ou plusieurs organisations. Dans la mesure du possible, les pull requests de traduction doivent être approuvées par un relecteur d'une organisation différente de celle du traducteur.
Une traduction doit avoir un minimum de deux mainteneurs. (Il n'est pas possible de relire et d'approuver son propre travail.)
Gestion des branches
Étant donné que les projets de traduction sont des efforts hautement collaboratifs, nous encourageons les équipes à travailler à partir d’une branche de développement partagée.
Pour collaborer sur une branche de développement:
-
A team member opens a development branch, usually by opening a new pull request against a source branch on https://github.com/kubernetes/website.
Nous recommandons le schéma de nommage de branche suivant :
dev-<source version>-<language code>.<team milestone>Par exemple, un approbateur d'une équipe de localisation allemande ouvre la branche développement
dev-1.12-de.1directement contre le dépôt k/website, basé sur la branche source pour Kubernetes v1.12. -
Les contributeurs individuels ouvrent des branches de fonctionnalités basées sur la branche de développement.
Par exemple, un contributeur allemand ouvre une pull request avec les modifications suivantes
kubernetes:dev-1.12-de.1surusername:local-branch-name. -
Les approbateurs examinent et mergent les branches de fonctionnalités dans la branche de développement.
-
Périodiquement, un approbateur fusionne la branche de développement à sa branche source.
Répétez les étapes 1 à 4 au besoin jusqu'à ce que la localisation soit terminée.
Par exemple, les branches de développement allemandes suivantes le seraient : dev-1.12-de.2, dev-1.12-de.3, etc.
Les équipes doivent fusionner le contenu localisé dans la même branche de publication d'où provient le contenu. Par exemple, une direction du développement provenant de release-1.23 doit se fonder sur release-1.23.
Un approbateur doit maintenir une branche de développement en la tenant à jour avec sa branche source et en résolvant les conflits entre les branches. Plus une branche de développement reste ouverte longtemps, plus elle nécessite généralement de maintenance. Envisagez de merger périodiquement les branches de développement et d’en ouvrir de nouvelles, plutôt que de conserver une branche de développement extrêmement ancienne.
Seuls les approbateurs peuvent accepter les pull requests, mais n'importe qui peut en ouvrir une avec une nouvelle branche de développement. Aucune autorisation spéciale n'est requise.
Pour plus d'informations sur le travail à partir de forks ou directement à partir du dépôt, voir "fork and clone the repo".
Upstream contributions
SIG Docs souhaite la bienvenue aux contributions et corrections upstream à la source anglaise.
A suivre
Une fois qu'une traduction répond aux exigences de logistique et à une couverture admissible, le SIG docs se chargera des taches suivantes:
- Activer la sélection de la langue sur le site Web
- Publier la disponibilité de la traduction via les canaux de la Cloud Native Computing Foundation, y compris sur le blog de Kubernetes.