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é à 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]]` de crochets, voire rajouter `en:` devant comme dans `[[en:computer]]` qui donne [[en:computer]] 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, dans la mesure du possible.
- _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)
## Notes
Discussion lors de la rédaction collaborative de la dépêche pour le noyau 3.14 publié le 23 ou 24 mars 2014 :
2014-03-21 20:26:59 baud 2014-03-21 08:55:58 cette partie a vocation a disparaître de la dépêche et ne sert que de « repère » lors de la rédaction, à la fin nous serons tout auteurs / contributeurs, ce qui est le propre d'un travail collaboratif :-) Si tu le souhaites, je lance la discussion sur la ML rédaction (+ une relance pour finir cette dépêche, Linus ayant annoncé que c'était la dernière rc)
2014-03-21 20:17:42 baud 2014-03-21 08:55:58 c'est la même notion que pour le packaging dans les distros, cela n'induit pas de notion de hiérarchie àmha (même si la distinction pourrait, a priori, le faire croire)
2014-03-21 08:55:58 ffourcot (mais je pense être contre à titre personnel pour cette distinction mainteneur/contributeur. Un mainteneur c'est un type qu'on verra régulièrement, c'est tout)
2014-03-20 14:08:18 rperier Fin bon après j'accepterai l'avis de la majorité hein, ce n'était qu'une proposition
2014-03-20 14:06:55 rperier A nouveau d'attribuer le status contributeur de relecture aux gens qui s'investissent vraiment et qui ont vraiment été utiles
2014-03-20 14:05:58 rperier La plupart du temps les relecteurs corrigent certaines choses, donc ils sont implicitement écrivains. C'est certe moins utile que le contenu lui même mais utile quand même et une contribution comme une autre ;)
2014-03-20 13:56:01 maboiteaspam muè, franchement honneur aux mainteneurs et écrivains selon moi. C'est moche mais je suis d'accord avec mupuf, la trad n'est pas suffisante et mal aisé au regard de l'anglais courant manipulé.
2014-03-20 13:02:38 rperier Dans la partie contributions à la fin de l'article, il serait peut être bien d'ajouter une section "Relecture" qu'en pensez vous ? histoire de créditer les personnes qui ont contribués à l'amélioration de la dépeche (orthographe, tournures de phrases etc)
2014-03-19 12:31:20 andrianarivony Désolé je n'ai vraiment pas pu être présent. Je vais essayer de faire une grosdse relecture / unification cet après midi quand même.
2014-03-17 20:31:55 illwieckz j’ai contribué la rc7 et proposé une traduction (j’ai laissé quelques termes techniques entre 4 points d’interrogation comme ceci: ??both core??, libre à qui veut d’améliorer :)
2014-03-17 11:57:42 mupuf Le but du mainteneur, c'est de forcer une personne à s'investir et suivre les mises à jour pour avoir une vision plus globale du développement. Sans mainteneur, on est à la merci des traductions bêtes et méchantes des commit logs. Parfois, on a même droit à des contre sens complets.
2014-03-17 11:56:13 mupuf 2014-03-14 19:11:47 : Un mainteneur est quelqu'un qui a accepté d'être responsable de la partie sur le long terme. Si il y a déjà un mainteneur sur la partie, tu ne peux t'ajouter que dans la catégorie contributeur. Si tu penses pouvoir faire un meilleur travail sur le long terme, tu peux demander au mainteneur de te laisser la place