Bonne année 2021 à toutes et à tous ! 🌟♥️🍾

La 41ème réunion de l’équipe de traduction s’est tenue lundi 4 janvier 2021 à midi heure française. Elle a eu lieu cette fois-ci encore en visio-conférence via le logiciel Zoom.

Ordre du jour

• Statistiques
• Informations générales
  • Changements ayant eu lieu sur WordPress 5.6
  • Documentation de WordPress en français
    • Avancée des travaux
    • Responsables de la documentation FR et réunion dédiée
    • Nouvelle rubrique : accessibilité
• Questions de traductions débattues :
  • Traduction de « Email address »
  • Traduction de « Border radius »
  • Règles d’espacement autour du caractère « barre oblique »
  • Traduction de « Sticky header / sticky menu »

Participantes et participants

• @audrasjb
• @jdy68
• @flobogo
• @valer1e
• @btpub
• @clementpolito
• @crash_47
• @chaton666
• @selfemedia

Informations générales

Statistiques et évolution par rapport à la dernière réunion

• 5 Locale Managers
• 7 GTE (dont 4 actifs)
• 9 GPTE
• 166 PTE
• 2376 contributrices et contributeurs soit 50 traductrices et traducteurs de plus depuis la dernière réunion ! 🥂🍾

Rappel des différents rôles :

• Locale Manager : Gestionnaire de la Locale (pour nous, fr_FR) – Les LM sont responsables du site fr.wordpress.org dans son ensemble. Ce sont les quatre GTE actuels de WordPress ainsi que certains des traducteurs historiques (même inactifs) et enfin le président de l’association WPFR (ce fonctionnement est propre à la locale fr_FR). 
• GTE : General Translation Editor – responsable général de la traduction pour la locale (ici fr_FR – français de France). Peut modifier/valider tous les projets, y compris le cœur WP.
  Les anciens GTE conservent actuellement leur rôle même s’ils sont inactifs.
• PTE : Project Translation Editor – responsable de la traduction d’un projet (un thème, une extension…)
• GPTE : Global Project Translation Editor – comme les PTE mais pour tous les thèmes, toutes les extensions ou les deux à la fois.

Informations générales

Changements ayant eu lieu sur WordPress 5.6

Les suites des changements effectués sur WordPress 5.6 afin d’améliorer l’inclusivité du logiciel on été brièvement discutées.

• Nous avons reçu une vingtaine/trentaine de messages de remerciement et nous les accueillons chaleureusement.
• 5 commentaires hostiles à ces changements ont également été publiés en commentaire de l’article d’annonce. Nous avons essayé d’y répondre le plus clairement possible et de façon transparente. Nous notons que les commentateurs n’ont pour l’instant pas donné suite aux réponses apportées.
• Un « fork » ainsi qu’une extension ont été créé sur GitHub afin de maintenir une version alternative de la traduction officielle de WordPress en français. À ce jour, ce projet sur GitHub a été mis en favori par trois personnes et « forké » 2 fois. Il est sur la liste de suivi de 4 personnes.
• L’équipe de modération du forum WPFR (représentée par @flobogo et @btpub) n’a pas vu passer de sujets concernant d’éventuelles difficultés à passer de l’usage du menu « Utilisateurs » à « Comptes » ou à s’approprier la combinaison des termes masculins et féminins pour les rôles. Le seul fil de discussion du forum WPFR abordant ces changements à été ouvert par l’auteur ou l’autrice du « fork » de la traduction.
• Les agences et freelances de la communauté FR n’ont pas remonté de difficultés particulières avec leurs clients à notre connaissance.

Nous prenons acte de ces éléments et nous suivrons attentivement d’éventuels nouveaux retours. À l’heure actuelle et presque un mois après la sortie de WP 5.6, ces changements apparaissent donc comme étant objectivement viables. Vu le peu de retours (en regard du nombre de téléchargement de cette version de WP), il semble que la transition se soit pour l’essentiel faite sans difficulté. Nous referons un nouveau point si nécessaire lors de la prochaine réunion de l’équipe.

Documentation de WordPress en français

Avancée des travaux

@jdy68 a fait un compte-rendu de l’avancée de la traduction de la documentation de WordPress en français :

• 99 articles ont déjà été traduits, soit 44,4 % des articles disponibles sur la version anglaise (la documentation française est à ce jour la plus avancée, après la version anglaise).
• Plusieurs articles sont assignés à des personnes depuis plusieurs mois sans que ces articles soient encore publiés. Nous les mentionnons ici afin qu’elles puissent idéalement laisser un commentaire pour mettre à jour leur assignation sur les articles concernés : @audrasjb, @chaton666, @manooweb, @jaz_on, @valer1e, @picux, @wplmillet. N’hésitez pas à retirer votre nom des lignes associées sur le document ou à mettre un commentaire dans la ligne de chaque article si vous êtes toujours actif/active 😊

Nouvelles responsables de la documentation FR et réunion dédiée

Félicitations à Jenny Dupuy (@jdy68) et Marie Comet (@chaton666) qui sont maintenant officiellement co-responsables de la documentation de WordPress en français.

Compte-tenu du temps que prend la partie consacrée à la documentation dans la réunion de traduction, il est convenu de prévoir une réunion régulière dédiée à la documentation de WP en français. Les co-responsables reviendront vers nous à ce sujet 😇

Nouvelle rubrique dans la documentation : Accessibilité

Sur proposition de Marie, une nouvelle rubrique « Accessibilité » a été ajoutée à la documentation. Elle est d’ores et déjà accessible sur la page d’accueil de la documentation FR.

Cette catégorie n’existe pas dans la documentation anglophone, nous l’avons donc créée de toute pièce pour la documentation francophone en nous inspirant du handbook de l’équipe d’accessibilité de WordPress.

Questions de traductions débattues

Traduction de « Email address »

Un incohérence est présente dans le glossaire depuis des temps immémoriaux :

• l’anglais email est traduit en français par « e-mail »
• l’anglais email address est traduit en français par adresse de messagerie

En plus de manquer de cohérence, cela se traduit par des alertes GlotDict répétitives. Proposition est faite d’uniformiser les deux traductions

Traduction de « Border radius »

Il y a un problème important de cohérence sur l’ensemble du projet, ce terme étant à ce jour traduit de 15 façons différentes suivant l’outil de vérification de la cohérence des traductions sur l’ensemble du projet.

Il est par ailleurs nécessaire de distinguer le terme Border radius de la propriété CSS border-radius associée, afin d’éviter d’introduire des traductions dans du code CSS, ou de suggérer indirectement aux utilisatrices et utilisateurs de le faire.

Règles d’espacement autour du caractère « barre oblique »

@nicomollet a mis au débat sur le Trello de l’équipe de traduction l’utilisation de la barre oblique, posant la question de la possibilité d’apposer un espace avant et après la barre oblique lorsque le terme est utilisé seul, voire au sein d’une phrase.

La règle typographique actuellement utilisée est la suivante :

• Quand la barre oblique sépare deux mots, pas d’espace ni avant ni après.
  Exemple : « voici une astuce/aide que vous pouvez prendre en exemple »
• Quand elle sépare des groupes de mots ou des mots composés, des espaces avant et après permettent une meilleure lisibilité.
  Exemple : « voici une astuce / aide à l’utilisation que vous pouvez prendre en exemple »

En effet, dans le cas d’un mot composé ou d’un groupe de mots formant une expression, l’absence d’espace introduit une ambiguïté sur le terme concerné par la barre oblique. Pour reprendre l’exemple ci-dessus, si l’on écrit « voici une astuce/aide à l’utilisation que vous pouvez prendre en exemple », visuellement, on interprète la barre oblique comme séparant les termes « astuce » et « aide » et pas « aide à l’utilisation ». La présence d’espaces avant et après la barre oblique permet de diminuer un peu cette petite confusion.

Traduction de « Sticky header / sticky menu »

@audrasjb a demandé à l’équipe de considérer le remplacement de la traduction « épinglé » par « fixe » dans le cas d’un élément d’interface restant fixe (en terme de perception pour l’internaute) au sein de la fenêtre par rapport au défilement dans la page.

Par ailleurs, il propose de distinguer les « articles épinglés » (mis en avant au sein de la liste des articles) des éléments d’interface adoptant un comportement fixe à l’écran sous certaines conditions (défilement vers le bas par exemple).

Un autre argument concerne le fait que le terme « fixe » est à ses yeux bien plus communément utilisé et compris. Jb précise en revanche que cela repose sur des observations personnelles et ne relève pas d’une appréciation universelle et indiscutablement objective.

Enfin il y a selon lui un risque de confusion car les auteur·es d’extensions peuvent tantôt utiliser le terme Sticky menu, tantôt le terme Fixed menu. Dans un cas nous traduirons par « Menu épinglé » et dans l’autre par « Menu fixe ». En laissant la règle de traduction telle qu’elle, nous risquons donc d’avoir différentes traductions pour une même idée, ou une idée très similaire.

Plusieurs personnes présentes à la réunion se sont rangées derrière cette proposition et d’autres s’y sont opposées. Un consensus a donc été recherché.

@btpub et d’autres contributeurs ou contributrices répondent à cette proposition que l’élément n’est techniquement pas fixe, puisqu’il se déplace tout au long du défilement afin de rester épinglé sur une zone de l’écran. La terme « menu fixe » ne leur paraît pas spécialement plus simple à comprendre pour les internautes que le terme « épinglé ».

Enfin, il ne paraît pas pertinent et peu viable d’avoir deux traductions différentes pour le terme « sticky », suivant que le terme concerne les articles mis en avant ou un élément épinglé au sein d’une zone de l’écran. Un consensus est trouvé autour de cette remarque.

D’autres contributeurs et contributrices proposent d’utiliser le terme « collé » ou « aimanté » mais ces propositions ne sont pas retenue pour la même raison.

Fin de la réunion à 13h05. Merci à tous et toutes pour votre participation.