Guide des traducteurs
FAQ des traducteurs de Darktable en français
Que ce soit pour la documentation ou pour l’Interface Utilisateur (UI), un groupe Signal “Darktable en français” existe pour permettre aux contributeur⋅ices d’échanger sur ces sujets. Les traducteur⋅ices sont chaleureusement invité⋅es à le rejoindre.
En cas de doute, quel qu’il soit, et pour limiter le surcroît de travail éventuel pour soi ou pour d’autres, il suffit d’en faire part dans ce groupe.
Les termes employés dans l’Interface Utilisateur sont, a priori, la référence.
Cependant, il peut exister des cas où ils soient discutables. Là aussi, le groupe Signal est là pour en débattre, proposer une ou des alternatives, prendre des décisions communes et y remédier quand on est d’accord.
1. Traduction de la documentation
La documentation d’origine en anglais à traduire se trouve ici. Tout autre documentation n’est pas ou plus d’actualité.
Le chapitre Contribuer au Docs est plus ou moins à jour (à la date de rédaction de ce guide).
Il serait à reprendre par endroit. S’assurer auprès de ses pairs en cas de doute.
À fin septembre 2026, la traduction française de la documentation est réalisée à 98%. Cela signifie que le reste à traduire ne concerne pratiquement que de nouvelles fonctionnalités présentes dans la version master du logiciel, qu’il faut bien entendu installer.
Ces nouvelles traductions, qui doivent correspondre à l’Interface Utilisateur, figureront dans la prochaine version stable, et régulièrement mise en ligne pour la version master.
1.1 Utilisation de Weblate
La documentation de Weblate est accessible via ce lien.
Les bases de la traduction avec Weblate sont accessibles via ce lien dans la-dite documentation.
Il faut un compte Weblate.
La traduction de la documentation de Darktable sur Weblate est accessible ici.
La section État des chaînes dans cette page liste, éventuellement :
- Toutes les chaînes
- Chaînes traduites
- Chaînes non terminées
- Chaînes non traduites
- Chaînes à vérifier
- Chaînes avec des vérifications en échec
- Chaînes traduites avec des vérifications de qualité ignorées
- Vérifications en échec : Majuscules multiples
- Vérifications en échec : Espaces au début
- Vérifications en échec : Espacement de ponctuation
- Vérifications en échec : Traduit par le passé
- Vérifications en échec : Liens Markdown
- Vérifications en échec : Syntaxe Markdown
Classiquement, lea traducteur⋅ice choisira prioritairement Chaînes non traduites ou non terminées. Éventuellement à vérifier ou avec des vérifications en échec.
Lors de la traduction d’une chaîne, il est possible de :
- vérifier le texte d’origine en anglais dans la page de la documentation où il figure en y accédant via, dans la colonne de droite, Informations sur la chaîne > Emplacement de la chaîne source,
- vérifier ce qui n’est pas conforme une fois Enregistrer et poursuivre ou Enregistrer a été cliqué : en haut de la colonne de droite, Points à vérifier listera les anomalies détectées par Weblate dans la traduction,
- en cas de doute, et en cas de doute seulement, cocher la case À vérifier. Un⋅e autre traducteur⋅ice pourra intervenir, ce qui signifie quasiment refaire le travail de traduction. Il est souvent préférable de ne pas traduire une chaîne dont on n’est pas certain⋅e de la signification ou autre.
Le point à vérifier “Il manque un espace insécable avant le signe de ponctuation :.” peut soit :
- être ignoré (bouton),
- un NBS (Non Breakable Space ou espace insécable) inséré devant le :.
Concernant ces espaces de ponctuation française, on pourra se reporter au règles mentionnées sur le site Reverso.
Les chaînes traduites (sans besoin de vérification) sont régulièrement et automatiquement poussées dans le GitHub de la documentation officielle, puis en ligne via Hugo. Les traducteur⋅ices n’ont rien à faire par rapport à ce processus, juste attendre qu’il se déroule.
1.2 Syntaxe markdown
Pour ceux qui ne connaissent pas cette syntaxe, qui est à conserver lors de la traduction : Basic Syntax.
Il est impératif de conserver la syntaxe markdown (ou md) telle qu’elle figure dans la version orignale.
1.3 Choix de traduction
Darktable ou Darktable ?
Aujourd’hui on écrit Darktable avec une majuscule.
Faut-il mettre des majuscules aux titres ? Aux noms de modules ? Aux titres ?
On suit les normes de syntaxe naturelle du français : les titres commencent par une majuscule.
De même, utilisez des minuscules lorsque vous faites référence aux noms de module et aux contrôles, qui en ont dans l’Interface Utilisateur de Darktable.
Faut-il traduire les liens ?
Par exemple, quand on a ce genre de lien :
[_filmic rgb_](./filmic-rgb.md)
Il faut traduire ce qu’il y a entre [] conformément à ce qu’on trouve dans l’Interface Utilisateur, qui apparaîtra sur la page html, mais ne pas toucher au lien entre ().
Ainsi, la traduction de la chaîne précédente serait [_Filmique RVB_](./filmic-rgb.md).
Faut-il traduire les ancres #balise ?
Par exemple, quand on a :
[usage](#usage)
On peut traduire les deux, à condition que l’ancre (après le #) soit traduite aussi dans la page cible courante ou autre.
Car les ancres doivent être traduites en conformité directe avec le titre de chapitre qu’elles désignent.
Exemple : un titre de chapitre est “Flux relatif à l’affichage”, l’ancre correspondante si elle existe sera “flux-relatif-à-laffichage”.
On notera que :
- L’ancre est complètement en minuscules,
- les espaces sont remplacés par des tirets (le caractère moins : “-” ),
- l’ancre ne contient aucun caractère spécial, tel que ’ (apostrophe), “, #, %, @, &, *, !, etc. Cf. la liste ici.
2. Traduction de l’Interface Utilisateur
Dans ce qui suit, Interface Utilisateur sera noté UI (pour User Interface), l’acronyme généralement employé (ou IU).
2.1 Utilisation de GitHub
La traduction de l’UI est réalisée directement sur GitHub. Il est par conséquent nécessaire d’avoir un compte personnel GitHub.
Deux cas de figure se présentent :
- Traductions épisodiques,
- Nombreuses traductions plus ou moins fréquentes.
Dans le 1er cas, pour quelques modifications passagères de traduction, il est possible de les réaliser sur sa copie personnelle dans son compte GitHub, sans jamais rien copier sur sa machine. Tout se fait alors sur l’interface Web de GitHub.
Dans le 2nd cas, il est envisageable de cloner tout le dépôt GitHub de Darktable sur sa propre machine, travailler localement dessus dans sa partie “po” des traductions, puis renvoyer ses modifications locales sur son propre compte GitHub où on a également une copie de l’ensemble du dépot GitHub de Darktable et de là faire sa Pull Request pour qu’elles soient prise en compte.
1er cas : sans récupération sur son ordinateur
Connecté sur GitHub avec son propre compte, en haut à gauche, sélectionner dans la liste déroulante le dépôtdarktable-org/darktable. Puis, il faut en premier lieu, et une seule fois, créer un fork de Darktable (au complet) : sur le GitHub Darktable dans la section Code, à droite du titre Darktable (avec le logo Darktable à sa gauche), on repère le bouton Fork (1.4k) avec une flêche vers le bas (v).
Si on a déjà forké Darktable, on peut accéder directement à sa copie personnelle ou autrement cliquer sur + Create a new fork.
L’opération ou la bascule sur la copie personnelle terminée, on peut le vérifier grâce :
- à l’affichage en haut à gauche de la page de son nom d’utilisateur / Darktable (avec le pictogramme du fork)
- au titre où ce n’est plus le logo Darktable à gauche de Darktable, et au dessous duquel on peut lire forked from Darktable-org/Darktable
Il est IMPÉRATIF de toujours savoir sur quelle version on travaille : la version officielle ou son propre fork.
Attention !
Avant de travailler sur votre fork, il faut systématiquement et impérativement le synchroniser avec la source : Bouton Synch fork > Update
Puis on se rend dans le dossier po pour y modifier le fichier fr.po.
Pour cela, il est nécessaire de le passer en édition (crayon en haut à droite) car il est présenté en lecture seule.
La structure de ce fichier po, outre l’entête qu’on peut laisser tel quel, est la suivante :
Remarque : le champ msgctxt (contexte message) n’est pas systématique. S’il est absent, on ne le crée par en VF.
Par exemple :
Les lignes commençant par # (dièse) sont des commentaires.
Une fois la ou les traductions réalisées, il reste à ouvrir une Pull Request. Cette opération aura pour effet de soumettre la ou les modifications de traduction (dans la mesure où on n’est intervenu que sur fr.po…) au propriétaire du dépôt officiel, de référence.
Revenu sur sa racine personnelle de Darktable, et après avoir bien vérifier qu’on est toujours sur sa copie locale de Darktable, on clique sur le bouton Contribute, qui informe du nombre de “commits” en avance sur la branche master, puis Open pull request.
Une nouvelle page s’ouvre, titrée Open a pull request où on trouve :
- Able to merge si tout est conforme pour réaliser une Pull Request,
- Un champs Title où on écrira de manière relativement succincte qu’il s’agit d’une mise à jour de la traduction française, éventuellement avec un ou deux détails,
- Et dans la zone de texte Add a description, les détails des (re)traductions proposées. Toutes les rubriques ne sont pas nécessairement utiles, notamment si une ou des corrections de traduction ne sont pas consécutives à une issue (Referenced issue), etc. A priori, le champ Summary est celui a renseigner impérativement, en anglais, pour informer le lecteur de sa ou ses traductions à prendre en compte,
- le bouton vert en bas Create pull request qui peut se transformer en Create draft pull request (v), qu’on choisira selon qu’on a terminé ou pas.
Il reste à patienter un peu pour recevoir la réponse à cette Pull Request et la prise en compte ou pas de la traduction.
2nd cas : avec récupération sur son ordinateur
Il faut en premier lieu, et une seule fois, créer un fork de Darktable, la procédure est exactement la même que dans le 1er cas. Reportez-vous à ce paragraphe pour les détails.
Ensuite, sur votre ordinateur, clonez votre dépôt Darktable. Dans le répertoire de votre choix :
Vous pouvez également cloner le dépôt en ssh à condition d’avoir créé des clés ssh sur votre compte GitHub.
Une fois votre dépôt Darktable cloné, vous pouvez traduire les chaines (mots, phrases ou paragraphes). Les chaînes sont enregistrées dans des fichiers .po situés dans le répertoire src/po. L’outil qui permet de modifier aisément les fichiers po est poedit (disponible dans tous les dépôts).
À intervalles réguliers, pensez à enregistrer. Pensez aussi à valider votre travail dans votre dépôt local et à l’envoyer dans votre dépôt GitHub.
La syntaxe de git push varie selon qu’on a cloné en HTTP ou en SSH. On a tout avantage à compléter la configuration locale de Git pour ne pas avoir à saisir l’URL à chaque fois. les fichiers de configuration de Git se trouvent ici :
- Fichier global :
$HOME/.gitconfigpour votre nom et votre adresse mail. - Fichier local (par dépôt) : compléter les sections
[remote "origin"]et[branch "main"]De nombreux exemples de configuration sont disponibles sur Internet.
Attention !
Avant de travailler sur votre clone local, il faut impérativement synchroniser votre fork puis votre clone.
- Pour votre fork (sur GitHub) : bouton Synch fork > Update
- Pour votre clone local :
git pull
Comme pour git push, la syntaxe de git pull dépend du mode de transfert HTTP ou SSH et des informations saisies dans le fichier de configuration de votre dépôt local.
Quand vous avez achevé vos traductions et mis à jour votre fork sur GitHub, il reste à ouvrir une Pull Request à partir de votre fork. La procédure est la même que dans le 1er cas. Reportez-vous à ce paragraphe pour les détails.
De la même manière, il reste à patienter un peu pour recevoir la réponse à cette Pull Request et la prise en compte ou pas de la traduction.