Visualiser une révision

Rédiger des dépêches noyau

BAud : révision n°2 (11 février 2014 22:20:06)

En complément du [[[template-des-news-noyau]]] et afin de [[[participer à LinuxFr]]], quelques [[[rédacteur]]]s se sont organisés.

## les sites à suivre

Vous les connaissez sans doute déjà ?
Dans les grandes lignes, suivre les sites suivants pour trouver les informations pour rédiger :

-    https://lkml.org/
-    https://lwn.net/
-    http://www.linuxfoundation.org/news-media/lwf
-    http://www.h-online.com/open/
-    http://www.remword.com/kps_result/

Voir le §Appel aux volontaires pour s'ajouter (selon son rôle, à définir).

## le processus de rédaction

- le sommaire n'apparaît qu'après modération (ou une fois dépassé les 10000 caractères), c'est normal
- durant la phase de rédaction, le texte des annonces de Linus est copié/collé pour avoir en référence l'anglais pour aider à la relecture de la traduction (Linus emploie quelques expressions idiomatiques voire fleuries, toute relecture / transposition est intéressante). Ce texte en anglais est enlevé à soumission de la dépêche.
- la tribune de la dépêche permet de se coordonner histoire de se répartir les paragraphes :
  - choisissez votre sujet de prédilection ! Essayez d'indiquer quand vous pourrez travailler dessus afin de ne pas forcément rester en attente, si vous avez un empêchement, signalez-le, ça arrive à tout le monde
  - les remarques sont les bienvenues dans la tribune, mais n'hésitez pas à éditer, c'est comme un wiki (et vous serez dans les remerciements !)
- il est possible de faire appel à un ami ou des membres de LinuxFr intervenant sur le noyau (pour la pile graphique, c'est recommandé, histoire de ne pas simplement relayer certains points évoqués par phoronix :D)
- si vous pensez être nul en orthographe ou abuser des anglicismes, n'hésitez pour autant pas à contribuer un paragraphe ou deux ! (bon, si vous écrivez en mode SMS, abstenez-vous, on va dire). La rédaction est justement là pour permettre la relecture et les corrections au fur et à mesure (aussi connu comme _release early, release often_ que la plupart des francophiles anglophobes (re-)connaissent dans le libre :D). Le fond est privilégiée à la forme (il y a la relecture pour cela, qui vous bâchera peut-être au passage, c'est le jeu :p).


Pour ceux que le Markdown effraie, pas de souci, le fond est à privilégier sur la forme et sinon il y a [[[Aide-édition]]] (et l'anti-sèche au bas de la rédaction) pour aider. Quelques conventions tout de même :

- essayer d'identifier les termes anglais avec l'emphase `_` de part et d'autre (traduite par de l'italique par la plupart des CSS)
- pour les termes techniques, faisant partie du code ou assimilé (chemin dans l'arborescence),  "\`"  permet de le citer `tel quel`
- passer une ligne avant les listes permet d'avoir une liste à puces automatiquement générée
- éviter de mettre un lien hypertexte sur un seul mot (surtout `ici`), l'approche sémantique recommande d'inclure les termes représentatifs du lien (et les moteurs de recherche le prennent en compte)
- pour la première apparition d'un terme technique, mettre un lien vers wikipedia permettra d'approfondir, il suffit de l' \[\[encadrer]] voire rajouter \[\[en:computer]] devant pour envoyer vers le wikipedia anglais (page souvent plus fournie :/)


## les termes utilisés
Dans la mesure du possible par ordre alphabétique ou de préférence ou par thème :

On ne peut échapper aux anglicismes sur des dépêches telles que celle du noyau Linux, notre cher _kernel_, pour autant quelques efforts peuvent être faits

- _log_ : journal
- _merge-window_ : fenêtre de fusion
- _mise à jour_ ou _mise-à-jour_ : cela dépend si c'est le verbe de la phrase ou si c'est un nom (mineur), au pluriel cela donne _mises-à-jour_ (préféré)
- _patch_ : là c'est plus flou, le pluriel _patches_ est souvent préféré à patchs (ou pas)
- _pilote_ : est préféré à driver (qu'il faut pour autant conserver si c'est dans une phrase en anglais qui aurait été conservée ou dans un chemin de fichier, restons intelligent).
- _prendre en charge_ / _gérer_ : préférable à supporter (qui insupporte quelques-uns), _prise en charge_ et _gestion_ au lieu de support pour la même raison (si vous effectuez des corrections, n'oubliez pas les accords au féminin !). _Supporter_ est tout de même toléré lorsqu'il s'agit d'apporter de l'aide (par une distribution et ses équipes par exemple)