Bonjour,Pour participer à l'effort de migration, j'ai choisi 3 pages parmi les moins consultées, avec très peu de modifications…
Merci d'avance de vos relectures. Baptiste
diff --git a/french/devel/website/htmlediting.wml b/french/devel/website/htmlediting.wml
index 7d342af28c2..13793549760 100644
--- a/french/devel/website/htmlediting.wml
+++ b/french/devel/website/htmlediting.wml
@@ -2,7 +2,9 @@
#use wml::debian::common_tags
#use wml::debian::acronyms
#use wml::debian::toc
-#use wml::debian::translation-check translation="54b8009523a375d159be453194c05df95ade0ede" translation_maintainer="Nicolas Bertolissio"
+#use wml::debian::translation-check translation="648de6ad5bea60540e41a5733da0b761a34c7927"
+
+# Previous translator : Nicolas Bertolissio
<p>
Cette page est actuellement une version de travail.
@@ -33,7 +35,7 @@ traductions.
Les lignes des fichiers wml et des autres fichiers ne devraient pas
dépasser la taille d'un terminal standard. C'est plus facile à éditer sous
vi, il est plus simple d'y faire des recherches et plus aisé à traduire.
- C'est également important car CVS est orienté lignes et qu'il est plus
+ C'est également important car il est plus
difficile de résoudre des conflits dans de longues lignes.
</dd>
<dt>Placer les balises sur des lignes séparées si possible</dt>
diff --git a/french/devel/website/todo.wml b/french/devel/website/todo.wml
index 46fd8032b0b..7e0344edd1c 100644
--- a/french/devel/website/todo.wml
+++ b/french/devel/website/todo.wml
@@ -1,7 +1,9 @@
#use wml::debian::template title="Liste des choses à faire pour les pages web de Debian" BARETITLE=true
#use wml::debian::common_tags
#use wml::debian::toc
-#use wml::debian::translation-check translation="fec8d607f478cb64b87fed6cb217d4621db3f8fa" maintainer="Thomas Huriaux"
+#use wml::debian::translation-check translation="c5bc1c982167d35ed41702b617990a78decb417f"
+
+# Previous translator : Thomas Huriaux
<toc-display/>
@@ -167,6 +169,8 @@
<h3>/devel/website/*</h3>
<p>Coder toutes les meilleures utilisations courantes qui restent.</p>
+
+ <p>Documenter la migration de CVS Ã Git.</p>
<toc-add-entry name="cn">Problèmes avec la négociation de
contenu</toc-add-entry>
diff --git a/french/devel/website/working.wml b/french/devel/website/working.wml
index 33231cb1418..2763e9860e4 100644
--- a/french/devel/website/working.wml
+++ b/french/devel/website/working.wml
@@ -1,10 +1,10 @@
#use wml::debian::template title="Travailler sur les pages du site Debian" BARETITLE=true
#use wml::debian::toc
-#use wml::debian::translation-check translation="a2ecb1eb5e40411b648499a302c668a3eb820dfe" maintainer="Frédéric Bothamy"
-
-<toc-display/>
+#use wml::debian::translation-check translation="bc66db8592a5b03cf67480ae2e3df889eb158f0c"
+# Previous translator : Frédéric Bothamy
+<toc-display/>
<toc-add-entry name="general">Informations générales</toc-add-entry>
@@ -20,11 +20,11 @@ répertoire english/.</p>
<h3>Récupération partielle</h3>
-<p>Beaucoup de personnes n'auront pas besoin de toute l'arborescence CVS
+<p>Beaucoup de personnes n'auront pas besoin de toute l'arborescence Git
sous <code>webwml</code>, ce qui peut occasionner des fichiers manquants
et entraîner des erreurs à la compilation, au cas où un fichier
-important a été ajouté et qu'on n'a pas fait de <kbd>cvs update</kbd>
-dans le répertoire. Veuillez vérifier que vous avez bien tous les
+important a été ajouté et qu'on n'a pas de <q>checkout</q> complet.
+Veuillez vérifier que vous avez bien tous les
fichiers nécessaires (comme les fichiers .wmlrc) avant de vous plaindre
à nous.</p>
@@ -59,7 +59,7 @@ site.</p>
<h3>Quand vous ajoutez de nouveaux répertoires, ajoutez aussi le Makefile !</h3>
-<p>Il faut faire attention quand on ajoute un nouveau répertoire au CVS.
+<p>Il faut faire attention quand on ajoute un nouveau répertoire au dépôt Git.
Si le répertoire courant est indiqué dans ../Makefile, alors il
<b>faut</b> créer un Makefile dans ce répertoire ; sinon <tt>make</tt>
affichera un message d'erreur.</p>
@@ -95,7 +95,7 @@ traitant de la mise en forme.</h3>
<p>Réalisez toujours des rustines différentes ou des envois différents pour
les changements relatifs au contenu et les changements relevant de la mise en
page. Lorsque ces changements sont combinés, il est plus difficile pour les
-traducteurs d'identifier les différences. En lançant un <kbd>cvs diff</kbd> sur
+traducteurs d'identifier les différences. En lançant un <kbd>git diff -u</kbd> sur
des changements qui contiennent les deux types de modifications, vous pourrez
vous rendre compte de l'ampleur du problème.</p>
@@ -125,62 +125,9 @@ deux douzaines de personnes de faire quelque chose qui pourrait être
rapidement fait par une seule personne.</p>
<p>De plus, pour rendre de telles modifications plus faciles Ã
-appliquer, vous pouvez utiliser le script <code>smart_change.pl</code>
-du répertoire de plus haut niveau dans le module CVS webwml.</p>
-
-<h4>Utilisation de smart_change.pl</h4>
-
-<pre>smart_change.pl [options] origfile</pre>
-
-<p>Actuellement, seuls les fichiers de <code>/english/</code> sont
-autorisés comme <var>origfile</var>. <code>smart_change.pl</code>
-utilise les arguments suivants :</p>
-
-<dl>
- <dt><code>-s, --substitute=<var>REGEXP</var></code></dt>
- <dd>Spécifie une expression rationnelle Perl à appliquer aux
- fichiers source (peut être utilisée plusieurs fois). Par
- exemple :
- <pre>
- $> ./smart_change.pl -s "s,http://oldurl/,http://newurl/,g"; english/devel/index.wml
- $> cvs diff -u */devel/index.wml | less
- $> cvs ci -m "1.23: Updated oldurl to current location" */devel/index.wml
- </pre>
- La première commande effectue le changement, la deuxième vérifie
- le fichier original anglais et toutes ses traductions. Il est
- conseillé de faire cela pour vérifier les changements réels avant
- de les valider. Si tout vous semble correct, validez vos
- changements avec la troisième commande.
- </dd>
-
- <dt><code>-l, --lang=<var>STRING</var></code></dt>
- <dd>Traite la langue (peut être utilisé plusieurs fois). Si aucune
- langue n'est spécifiée, toutes les langues disponibles sont
- traitées.</dd>
-
- <dt><code>-n, --no-bump</code></dt>
- <dd>N'incrémente pas les numéros de version dans les en-têtes
- translation-check. Normalement, le numéro de version de chaque en-tête
- translation-check est incrémenté d'un dans les fichiers traduits
- qui sont à jour et n'est pas modifié dans ceux qui ne sont pas à jour.
- Si cette option est spécifiée, aucun en-tête translation-check
- n'est modifié. Voir <q>Maintenir les traductions à jour</q>
- pour une <a href="uptodate">explication sur les en-têtes
- translation-check</a>.
- </dd>
-
- <dt><code>-p, --previous</code></dt>
- <dd>Affiche la précédente révision CVS. Ceci est principalement
- utile quand les fichiers anglais ont déjà été validés et que vous
- voulez vérifier les en-têtes translation-check par rapport à la
- version précédente.</dd>
-
- <dt><code>-h, --help</code></dt>
- <dd>Affiche un court message d'information sur l'utilisation.</dd>
-
- <dt><code>-v, --verbose</code></dt>
- <dd>Affiche des messages verbeux lors de l'exécution.</dd>
-</dl>
+appliquer, vous pouvez utiliser le script
+<a href="using_git#translation-smart-change"><code>smart_change.pl</code></a>
+du répertoire de plus haut niveau dans le module Git webwml.</p>
<toc-add-entry name="links">Liens</toc-add-entry>
@@ -330,10 +277,10 @@ répertoire ne seront pas mises à jour automatiquement.</p>
web.</p>
<pre>
mkdir foo
- cvs add foo
+ git add foo
cd foo
cp ../intro/Makefile .
- cvs add Makefile
+ git add Makefile
</pre>
<p>�ditez le Makefile dans le répertoire parent et ajoutez le répertoire
@@ -342,5 +289,5 @@ ce répertoire lors de la prochaine compilation quand make est lancé.</p>
<p>Enfin, enregistrez tous les changements effectués avec</p>
<pre>
- cvs commit Makefile foo
+ git commit Makefile foo
</pre>
#use wml::debian::template title="Usage pour le HTML des pages du site de Debian" BARETITLE=true
#use wml::debian::common_tags
#use wml::debian::acronyms
#use wml::debian::toc
#use wml::debian::translation-check translation="648de6ad5bea60540e41a5733da0b761a34c7927"
# Previous translator : Nicolas Bertolissio
<p>
Cette page est actuellement une version de travail.
</p>
<toc-display/>
<toc-add-entry name="preface">Préface</toc-add-entry>
<p>
Cette page est là pour aider les auteurs et les traducteurs à créer des pages
correctement formatées. Elle contient des conseils sur l'utilisation des
balises et sur la manière de créer de nouvelles pages et de les rendre plus
faciles à traduire.
</p>
<toc-add-entry name="general">Quelques conseils généraux</toc-add-entry>
<p>
Voici une liste de conseils généraux pour les nouvelles pages ou les
traductions.
</p>
<dl>
<dt>Ne pas utiliser de longues lignes</dt>
<dd>
Les lignes des fichiers wml et des autres fichiers ne devraient pas
dépasser la taille d'un terminal standard. C'est plus facile à éditer sous
vi, il est plus simple d'y faire des recherches et plus aisé à traduire.
C'est également important car il est plus
difficile de résoudre des conflits dans de longues lignes.
</dd>
<dt>Placer les balises sur des lignes séparées si possible</dt>
<dd>
La plupart des balises HTML peuvent être placées sur des lignes séparées
comme par exemple <div>, <p>, <table> et <ul>. Pour
faciliter les choses aux traducteurs, vous devriez placer toutes les
balises qui peuvent être utilisées de cette façon sur des lignes séparées.
Sinon les traducteurs pourraient effacer accidentellement ces balises et
oublier de les remettre dans leur traduction.
</dd>
<dt>Ne pas utiliser d'espaces ou de sauts de lignes dans les balises situées
dans le texte</dt>
<dd>
Certaines balises produisent un espace si elles sont placées sur des lignes
séparées. Par exemple la balise <q> utilisée pour de courtes
citations et de courts extraits. Vous ne pouvez les séparer sur une ligne
que comme un tout avec leur contenu, sinon il pourrait y avoir un espace
entre le contenu et la balise dans la page HTML. � l'intérieur de ces
balises vous pouvez avoir autant de sauts de lignes ou d'espaces que vous
le souhaitez entre les mots.
</dd>
</dl>
<toc-add-entry name="abbreviations">Abréviations et acronymes</toc-add-entry>
<p>
Pour les abréviations et les acronymes, la balise HTML <acronym> devrait
être utilisée. Il y a deux raisons pour ne pas recommander l'utilisation de la
balise <abbr> : d'abord tous les navigateurs ne la gèrent pas et
ensuite les définitions d'un acronyme et d'une abréviation sont incohérentes
(N. d. T. : en anglais peut-être, mais pas en français).
</p>
<p>
Un acronyme devrait être ajouté à la page avec la syntaxe suivante :
<code><acronym lang="code de langue" title="Définition complète de
l'acronyme">ACRONYME</acronym></code>. Le titre devrait contenir la
totalité des mots prononcés. Les lettres des mots devraient être capitalisées
selon l'usage français. L'attribut « lang » n'est requis que si
l'acronyme ou l'abréviation est en langue étrangère.
</p>
<p>
Il y a déjà un ensemble d'acronymes usuels dans les modèles wml à utiliser dans
vos pages, vous devriez ajouter une ligne pour utiliser les
<code>acronyms</code> dans le fichier wml. Par exemple, la balise wml pour DD
est <acronym_DD />.
</p>
<toc-add-entry name="citations">Citations et extraits</toc-add-entry>
<p>
Il existe plusieurs règles différentes sur ce qu'est une citation ou un extrait
pour différentes langues. Si vous avez une courte citation dans le texte, vous
devriez utiliser la balise <q>. L'affichage du contenu est géré par la
feuille de style de la langue. Les balises <q> ne devraient pas avoir
d'espace ou de saut de ligne entre la balise ouvrante ou fermante et le
contenu.
</p>
<p>
Pour des citations plus longues, la balise <blockquote> devrait être
utilisée. Une balise <blockquote> délimite un ou plusieurs paragraphes de
texte qui sont marqués par <p>. Veuillez ne pas utiliser les balises
<blockquote> pour centrer un bloc de texte qui n'est pas une citation.
Les blockquotes sont exclusivement réservés aux citations et seront affichés
par une feuille de style spécifique à la langue à l'avenir.
</p>
<p>
Il existe également une balise <cite> en HTML. Cette balise <cite>
n'est pas utilisée pour le texte de la citation lui-même. Elle est utilisée
pour la source de la citation. Ce peut être le nom de la personne citée ou une
URL si elle est ajouté comme attribut dans une balise <blockquote>.
</p>
<toc-add-entry name="code">Noms de programmes et code</toc-add-entry>
<p>
Pour les noms de programmes et le code informatique, il existe une balise
nommée <code>. Les navigateurs devraient normalement savoir comment
afficher le code et les noms de programmes, mais l'affichage peut aussi être
modifié par une feuille de style. Utiliser <tt> n'est pas une bonne idée
car cela ne renseigne pas sur le contenu.
</p>
<toc-add-entry name="samp">Exemples d'affichages d'ordinateur</toc-add-entry>
<p>
Pour les affichages d'ordinateur à l'écran, il existe une balise spéciale
nommée <samp>. Si vous avez un grand bloc d'affichage, vous devriez
également regarder dans le fichier de feuille de style si une classe
particulière existe.
</p>
<toc-add-entry name="kbd">Saisie au clavier</toc-add-entry>
<p>
S'il y a des exemples où l'utilisateur doit saisir quelque chose au clavier, la
balise <kbd> devrait être utilisée pour la saisie de l'utilisateur.
Veuillez également vous reporter au chapitre sur les <a href="#var">\
variables</a> pour savoir comment baliser les saisies variables.
</p>
<toc-add-entry name="var">Variables</toc-add-entry>
<p>
Parfois, il est nécessaire d'indiquer qu'une entrée variable telle qu'une
adresse IP particulière ou un nom d'utilisateur doit être fournie à un
programme sur la ligne de commande. Pour ces entrées variables, la balise
<var> devrait être utilisée.
</p>
<toc-add-entry name="pre">Contenu préformaté</toc-add-entry>
<p>
La balise <pre> ne devrait être utilisée que pour le texte préformaté. La
longueur des lignes, les espaces et d'autres choses seront préservés.
Naturellement, cette balise ne peut pas contenir la plupart des autres balises
HTML.
</p>
<toc-add-entry name="img">Images</toc-add-entry>
<p>
Si des images sont ajoutées à la page, il n'est pas nécessaire d'ajouter un
attribut border=0 invalide. Mais, si possible, la taille de l'image et un
attribut <code>alt</code> devraient être ajoutés. La taille devrait être
ajoutée par wml si elle n'est pas présente mais cela demande du temps de
compilation. L'attribut <code>alt</code> devrait contenir quelque chose qui
explique aux utilisateurs navigant avec lynx et aux aveugles ce que contient
l'image.
</p>
# <toc-add-entry name=""></toc-add-entry>
#use wml::debian::template title="Liste des choses à faire pour les pages web de Debian" BARETITLE=true
#use wml::debian::common_tags
#use wml::debian::toc
#use wml::debian::translation-check translation="c5bc1c982167d35ed41702b617990a78decb417f"
# Previous translator : Thomas Huriaux
Faire une page pour les anciens dons, nous ne voulons pas les oublier, mais ils ne doivent pas surcharger la page des dons actuels. La même chose pour les partenaires.
Séparer les longues parties de données non traduisibles de la page donations. Voir /mirror/sponsors pour commencer.
Toutes les informations spécifiques aux portages doivent se trouver dans les pages sur les portages. (Il s'agit plutôt d'un souhait perpétuel qui ne pourra jamais être corrigé.) :)
Parcourir les portages listés comme non maintenus dans le fichier port.maintainers et les corriger.
Importer les pages du portage sh.
Cette page doit être raccourcie et fournir des informations plus détaillées au travers de liens. Il y a eu une suggestion sur la création d'une page de recommandations avec des liens vers les autres projets libres que Debian soutient.
Un exemple concerne les licences. J'ai écrit [treacy ?] quelques petites choses dessus, mais cela devrait vraiment être déplacé sur les pages respectives (voyez intro/license_disc.wml). Nous devons convaincre les personnes que certaines licences sont mieux que d'autres. Il semble que cela devrait également être lié avec la page de recommandations.
�crire une introduction sur quelque chose comme Debian n'est vraiment pas facile. Vous avez vraiment besoin de réfléchir sur comment diviser toutes les questions impliquées (mais liées entre elles).
Une nouvelle page comme mentionné ci-dessus. La LPF doit avoir un lien dessus (c'est ce qui a lancé l'idée d'une page de recommandations).
Elle devrait sûrement être créée uniquement lorsque quelqu'un aura le temps de refaire tous les documents d'introduction. J'ai [treacy ?] beaucoup d'idées à ce sujet et je le ferai moi-même quand j'aurai suffisamment de temps.
Tous les sites web des vendeurs doivent être vérifiés pour s'assurer qu'ils contribuent toujours. Ils doivent également être vérifiés après chaque publication majeure de Debian.
Une autre solution serait de le déplacer vers un système de base de données. Il y a déjà une sorte de base de données interne, mais seul Craig en sait quelque chose.
Cette page est maintenue par Craig Small (csmall@debian.org)
Cette page doit être divisée (par continent, peut-être également par pays).
Beaucoup trop de choses redondantes sont laissées dans les fichiers à traduire ; il faudrait faire la même chose que ce que nous (treacy avec un peu d'aide de joy) avons fait avec les fichiers .data dans security/. En outre, cela permettrait de n'avoir qu'un seul endroit pour signaler si un événement est passé ou actuel, ce qui est loin d'être négligeable.
Les marques pour le titre, l'auteur, la langue, le lien et la disponibilité devraient être séparées de la partie à traduire de la page.
Aider le secrétaire à maintenir ces pages.
Décider si nous devons garder les modèles basic et votebar ou si nous devons utiliser un seul modèle (« votepage » ou quelque chose de semblable).
Vous pouvez trouver une \ liste des choses à faire dans le \ dépôt Git.
Les scripts sont actuellement maintenus par Frank « djpig » Lichtenheld et Martin « Joey » Schulze.
Retirer ces pages de /ports/ car il ne s'agit pas de portages Linux. (Renommer également /ports/ ?)
Nous devrions peut-être mettre en évidence quelques pages majeures en utilisant <strong> ou <em>.
« Nous devrions ajouter un avertissement sur lists.debian.org, signifiant que Debian se réserve le droit d'archiver tous les courriels qui arrivent chez Debian. » -- David Starner
Il y a dorénavant un tel avertissement sur /MailingLists/.
Aux alentours du 30 mai 2001, Apache, sur lists.d.o / cgi.d.o a décidé de n'accepter aucun argument aux scripts CGI. Un redémarrage a aidé. Trouver où était le problème.
Trouver pour les anciennes années les entrées <moreinfo> qui contiennent des mentions aux archives des listes au lieu d'en inclure le texte ou même d'en faire un lien, et les corriger.
Il y a beaucoup de bulletins de 1997 et du début de 1998 qui manquent d'informations supplémentaires basiques — les trouver et les documenter. D'une manière ou d'une autre. :)
Changer les pages qui ont l'information « fixed in » en une marque plutôt que dans le corps de la page, de manière à ce que nous puissions vérifier cette marque dans le modèle et ne pas afficher « Fixed in: » s'il est vide.
Rendre les pages du portage x86 plus utiles... d'une manière ou d'une autre :)
La diviser par sections ? Peut-être, si elle s'étend trop...
Cela est déjà partiellement corrigé en ayant différentes pages https://lists.debian.org/truc incluant un formulaire d'inscription et de désinscription.
�crire un avertissement sur la vérification contre les abus.
Récupérer ailleurs tous les représentants de Debian qui manquent encore, vérifier et maintenir les actuels.
Coder toutes les meilleures utilisations courantes qui restent.
Documenter la migration de CVS Ã Git.
Le système de négociation de contenu a quelques défauts qui repoussent certaines personnes à visiter notre site. Cependant nous ne pouvons pas faire beaucoup pour cela. Les clients envoyant des chaînes non conformes avec le RFC dans l'en-tête Accept-Language sont la principale cause de ce problème. Apache devient instable et applique certaines de ses méthodes illogiques pour fournir le plus petit fichier disponible.
Lorsque « * » est donné dans l'en-tête Accept-Language, la première page disponible sera fournie, et il est plus que probable que ce ne sera pas l'anglais, mais l'arabe ou le chinois. Cela est particulièrement problématique lorsque la préférence de langue de l'utilisateur est un code de langue en deux parties (comme « en-ca » ou « nl-BE »), suivi par « * ».
Apache 1.3 est ici fidèle au RFC. Le code de Apache 2.0 retournera respectivement en ou nl, mais en utilisant une priorité faible, donc cela n'aidera probablement pas avec par exemple « en-ca, fr-ca, * ».
De plus, lorsqu'il existe un fichier d'une langue inconnue, c'est-à -dire un fichier non reconnu truc.*.html sans spécification AddLanguage ou LanguagePriority, et lorsque le client envoie un Accept-Language qui ne contient que des langues non disponibles, le premier fichier sera fourni.
Cela arrive le plus souvent avec la page /releases/potato/i386/install car il y a une version slovaque et nous n'avons pas configuré cette langue dans Apache car il n'y a pas de traduction du site web en slovaque. Nous avons contourné le problème en incluant sk aux fichiers de configuration d'Apache, mais comme d'habitude, les changements ne se propagent pas rapidement à tous les miroirs.
Les sites sont supposés créer le fichier mirror/timestamps/<hôte>. Jay a écrit des scripts qui vérifient la date dans ce fichier pour chaque miroir, de manière à ce que nous puissions savoir lorsqu'un miroir est dépassé. Voyez mirror/timestamps/*.py.
Nous devrions réduire le nombre de miroirs web en Europe et l'augmenter sur les continents moins équipés en connexions.
Que la mise à jour de tous les miroirs se fasse de manière « poussée » (à partir de www-master si possible) est également un objectif.
S'assurer que chaque miroir a la configuration correcte pour Apache est extrêmement pénible, mais il n'y a pas moyen d'y échapper. Phil Hands a suggéré que ce qui concernait « AddLanguage » soit placé dans un fichier accessible avec wget et que nous écrivions un script Perl qui mettrait automatiquement à jour les fichiers de configuration de Apache des gens.
Tous les liens dans l'archive devraient permettre à l'utilisateur
de choisir le site de téléchargement. La liste de miroir de master
pourrait être utilisée pour garder la liste des miroirs à jour
(peut-être même utiliser un script). Voyez les fichiers
webwml/english/mirror/Mirrors.masterlist et
webwml/english/mirror/mirror_list.pl.
La liste des miroirs est maintenues par les gens sur
mirrors@debian.org.
Les liens vers des pages externes doivent être vérifiés. James Treacy
a écrit un petit script Python à cette fin. Frank Lichtenheld maintient
actuellement ce script, les résultats (mis à jour quotidiennement)
peuvent être trouvés sur
Faites ce que vous voulez de cela.
Si cgi.debian.org se trouvait sur un hôte moins utilisé et plus rapide, nous pourrions avoir du contenu plus dynamique pour les pages web.
Finir de fusionner intro/businesses.wml.wrk dans
users/. Utiliser le modèle toc dans ce dernier.
Javier a suggéré de créer automatiquement des comptes pour les traductions des pages DDP.
Joey a dit :
Je préférerais voir un avertissement sur les pages de sécurité comme:
Veuillez noter que nous ne pouvons pas garantir qu'aucun intrus n'aura accès à nos serveurs, puisqu'ils sont connectés à Internet. Dans une telle situation, une personne malintentionnée pourrait potentiellement modifier les envois à security.debian.org et modifier les pages web contenant les sommes de contrôle MD5. Nous essayons cependant de faire de notre mieux pour éviter cela. Soyez conscient qu'il n'y a pas de sécurité à 100 %, mais uniquement des améliorations de l'état actuel.
Joey devrait probablement le reformuler. :)
Devrait être ajouté à /security/faq.
Vernon Balbert <vbalbert@mediaone.net> a suggéré que nous clarifions la version du noyau que nous utilisons dans la dernière version de Debian.
Matti Airas <mairas@iki.fi> a suggéré de « sélectionner la langue avec le module mod_rewrite de Apache. Au lieu de devoir aller explicitement sur https://www.debian.org/intro/about.en.html (ou un miroir quelconque), il serait possible d'aller sur https://www.debian.org/en/intro/about, mod_rewrite remplaçant alors l'adresse par le lien corrigé. » Veuillez noter que cela nécessiterait des bidouillages supplémentaires pour ne pas casser les liens relatifs.
Chris Tillman a suggéré :
Il est souvent difficile de définir quelles machines sont gérées ou pas par Debian. Il y a un champ infini de machines, pour ne pas mentionner cartes réseaux, écrans, souris, cartes vidéos, cartes son, types de port, etc. qu'un simple système peut mélanger. Beaucoup de pages sur les portages sont dépassées.
Debian gère beaucoup de systèmes. Je pense qu'il serait sensé de commencer à essayer de lister spécifiquement lesquels. De plus, il serait très agréable de savoir lesquels ne sont pas gérés, à la fois pour les nouveaux utilisateurs potentiels et en tant que liste des choses à faire pour les développeurs.
Je pense que la façon la plus facile de le faire serait de proposer une page web où les gens pourraient entrer les composants de leur système, de préférence en les choisissant à partir d'une liste de composants connus avec une option « autres ». Ensuite, ils pourraient fournir les plus et les moins de Debian sur cette architecture, ainsi que tous les problèmes spécifiques.
Ensuite, après la soumission des spécifications matérielles de l'utilisateur, le système pourrait montrer une liste (datée) d'expériences d'utilisateurs avec ces composants.
Nous devrions également compléter cette page avec des liens vers la documentation d'installation, les FAQ, et probablement même ajouter un lien sur la page principale de Debian.
La liste de nos rapports de bogue.
Veuillez proposer quoi que ce soit d'autre sur notre liste de diffusion.
#use wml::debian::template title="Travailler sur les pages du site Debian" BARETITLE=true
#use wml::debian::toc
#use wml::debian::translation-check translation="bc66db8592a5b03cf67480ae2e3df889eb158f0c"
# Previous translator : Frédéric Bothamy
<toc-display/>
<toc-add-entry name="general">Informations générales</toc-add-entry>
<h3>Ressources nécessaires</h3>
<p>Si vous voulez travailler sur notre site web, vous devez vous
préparer à accueillir au moins 250 Mo de données sur votre disque dur. Ce
chiffre reflète l'état actuel de l'archive. Si vous reconstruisez
(accidentellement) toutes les pages, vous aurez au moins besoin du
double de place. Et si vous ne récupérez qu'une partie des sources, vous
aurez besoin de nettement moins d'espace, par exemple 50 Mo pour le
répertoire english/.</p>
<h3>Récupération partielle</h3>
<p>Beaucoup de personnes n'auront pas besoin de toute l'arborescence Git
sous <code>webwml</code>, ce qui peut occasionner des fichiers manquants
et entraîner des erreurs à la compilation, au cas où un fichier
important a été ajouté et qu'on n'a pas de <q>checkout</q> complet.
Veuillez vérifier que vous avez bien tous les
fichiers nécessaires (comme les fichiers .wmlrc) avant de vous plaindre
à nous.</p>
<h3><q>Que sont ces lignes commençant par « # » ?</q></h3>
<p>Avec wml, les lignes commençant par « # » sont des
commentaires. Ils sont utilisés de préférence aux commentaires HTML, car
ils n'apparaissent pas dans le code produit.</p>
<p>Veuillez lire la page sur l'<a href="using_wml">utilisation de
WML</a> pour plus d'informations sur WML.</p>
<toc-add-entry name="etiquette">Consignes pour les éditeurs</toc-add-entry>
<h3><q>Puis-je modifier la version anglaise ?</q></h3>
<p>Cela dépend. Si vous voyez une petite erreur, comme une faute de
frappe, corrigez-la.</p>
<p>Si vous vous rendez compte qu'une information est manquante, vous
pouvez aussi la corriger.</p>
<p>Si vous pensez que quelque chose ne va pas et doit être réécrit,
dites-le sur debian-www afin que cela soit discuté. Nous serons
certainement d'accord avec vous.</p>
<p>Si vous remarquez un problème dans un fichier modèle (c'est-à -dire un
fichier dans le répertoire webwml/english/template/debian), réfléchissez
à deux fois avant de le corriger, parce que les changements dans ces
fichiers entraînent souvent la reconstruction d'une grande partie du
site.</p>
<h3>Quand vous ajoutez de nouveaux répertoires, ajoutez aussi le Makefile !</h3>
<p>Il faut faire attention quand on ajoute un nouveau répertoire au dépôt Git.
Si le répertoire courant est indiqué dans ../Makefile, alors il
<b>faut</b> créer un Makefile dans ce répertoire ; sinon <tt>make</tt>
affichera un message d'erreur.</p>
<h3>Utilisez un anglais simple et clair.</h3>
<p>Comme le site Debian est consulté par des personnes dont l'anglais
n'est pas la langue maternelle et qu'il est traduit dans d'autres langues,
il est préférable d'écrire avec un anglais simple et clair et d'éviter
l'argot, les émoticônes, les idiomes et le vieil anglais.
</p>
<p>Si vous en utilisez néanmoins, ajoutez un commentaire au fichier
source expliquant le sens de la phrase.</p>
<p>
En cas de doute, ou pour relire votre proposition, veuillez
contacter l'<a href="mailto:debian-l10n-english@lists.debian.org";>\
équipe de localisation en anglais</a>.
</p>
<h3>Cherchez le README dans les répertoires anglais.</h3>
<p>Certains répertoires contiennent un fichier README qui peut vous
aider à comprendre comment ce répertoire est organisé. Il peut
fournir des informations utiles lorsqu'on travaille dans un tel
répertoire.</p>
<h3>Envoyez séparément les modifications concernant le contenu et celles
traitant de la mise en forme.</h3>
<p>Réalisez toujours des rustines différentes ou des envois différents pour
les changements relatifs au contenu et les changements relevant de la mise en
page. Lorsque ces changements sont combinés, il est plus difficile pour les
traducteurs d'identifier les différences. En lançant un <kbd>git diff -u</kbd> sur
des changements qui contiennent les deux types de modifications, vous pourrez
vous rendre compte de l'ampleur du problème.</p>
<p>De manière générale, évitez les changements aléatoires de mise en
forme. Il ne faut pas modifier des parties existantes des pages pour
les rendre compatibles avec XHTML/XML et en même temps, apporter
d'autres modifications. Bien évidemment, les ajouts devraient dès
le départ être écrits proprement.</p>
<h3>Si possible, mettez également à jour les traductions.</h3>
<p>Certains changements sont indépendants de la langue utilisée dans le
fichier WML, comme des changements dans des URLs ou dans du code Perl
inclus. Corriger les erreurs typographique entre également dans la même
catégorie car les traducteurs ont pour habitude de les ignorer lors de
la traduction. Pour tous ces changements indépendants de la langue, vous
pouvez faire le même changement dans tous les fichiers traduits sans
connaître réellement les autres langues et incrémenter de manière
sécurisée la version dans les en-têtes translation-check.</p>
<p>Il n'est pas très difficile pour les traducteurs de faire le
même travail eux-mêmes et il peut être peu pratique pour les éditeurs
anglophones d'avoir un export complet sur lequel opérer. Cependant, nous
encourageons toujours les personnes à le faire pour éviter de demander Ã
deux douzaines de personnes de faire quelque chose qui pourrait être
rapidement fait par une seule personne.</p>
<p>De plus, pour rendre de telles modifications plus faciles Ã
appliquer, vous pouvez utiliser le script
<a href="using_git#translation-smart-change"><code>smart_change.pl</code></a>
du répertoire de plus haut niveau dans le module Git webwml.</p>
<toc-add-entry name="links">Liens</toc-add-entry>
<h3><q>Ce lien ne semble pas marcher, dois-je le changer ?</q></h3>
<p>� cause de la façon dont les serveurs web sont configurés (utilisant
<a href="content_negotiation">la négociation de contenu</a>),
vous ne devriez pas avoir besoin de changer les liens du site.
En fait, nous vous suggérons de ne jamais le faire. �crivez à debian-www
si vous pensez qu'un lien est cassé avant de le changer.</p>
<h3>Correction des liens</h3>
<p>Si vous trouvez un lien vers un site externe qui renvoie une
redirection (301, 302, redirection par <meta> ou une page indiquant
<q>This page has moved.</q>), merci de le signaler
sur debian-www.</p>
<p>Si vous trouvez un lien cassé (404, 403, ou une page qui n'est
manifestement pas celle indiquée dans le lien), veuillez le corriger et
en informer debian-www afin d'avertir les traducteurs. Ou alors corrigez
aussi le lien pour toutes les traductions, en faisant attention de
mettre à jour la ligne <code>#use wml::debian::translation-check</code>.</p>
<h3><q>Que sont ces fichiers truc.def et truc.data ?</q></h3>
<p>Afin de faciliter la maintenance des traductions, nous
séparons les parties génériques (données) du texte sur certaines pages.
Les traducteurs ne doivent copier et traduire que la partie textuelle,
les données seront ajoutées automatiquement.</p>
<p>Un exemple peut être utile à mieux comprendre ; plusieurs
fichiers sont nécessaires pour générer la liste des vendeurs dans
<code>CD/vendors</code> :</p>
<dl>
<dt><code>index.wml</code> :</dt>
<dd>Le texte en haut de la page sur les vendeurs est dans ce fichier.
Une traduction devrait être placée dans votre répertoire.</dd>
<dt><code>vendors.CD.def</code> :</dt>
<dd>Celui-ci contient tous les morceaux de texte qui sont nécessaires
à chaque entrée dans la liste. Les traductions sont mises dans le
fichier
<code><<var>langue</var>>/po/vendors.<var>xy</var>.po</code>.</dd>
<dt><code>vendors.CD</code> :</dt>
<dd>Ce fichier contient les données relatives aux vendeurs, qui
sont indépendantes de la langue, il ne doit donc pas être traduit.</dd>
</dl>
<p>Lorsqu'une des personnes derrière <email "cdvendors@debian.org">
ajoute un nouveau vendeur, elle l'ajoute dans <code>debiancd.db</code>,
fait la conversion au format WML dans le fichier <code>vendors.CD</code>
(avec le programme <code>getvendors.pl</code>), et ensuite laisse WML
et les Makefiles faire leur travail. Toutes les traductions seront
reconstruites à partir du texte actuellement traduit, mais avec les
données pour le nouveau vendeur (une mise à jour gratuite !)</p>
<toc-add-entry name="newpage">Ajouter de nouvelles pages</toc-add-entry>
<p>Ajouter de nouvelles pages à Debian est assez facile. Tout le travail
consistant à mettre le bon en-tête et le bon pied de page est déjà fait
en utilisant WML. Tout ce que vous avez besoin de faire est d'inclure une
ligne telle que la suivante en haut d'un nouveau fichier :</p>
<pre><protect>
#use wml::debian::template title="TITRE DE LA PAGE"
</protect></pre>
<p>suivi du corps de la page. Toutes les pages devraient utiliser le
fichier modèle
<code>wml::debian::template</code> sauf si elles en utilisent un spécial
créé uniquement pour leur section, comme par exemple les pages des
nouvelles ou celle sur la sécurité.</p>
<p>Les modèles que nous utilisons vous permettent de définir certaines
variables qui affecteront les pages créées. Cela devrait éviter d'avoir
à créer des modèles différents pour chaque situation et permettre que
les améliorations soient plus faciles à mettre en Å?uvre. Les variables
disponibles actuellement et leurs fonctions sont :</p>
<dl>
<dt>BARETITLE="true"</dt>
<dd>Supprime la partie « Debian -- » qui est
habituellement ajoutée au début des balises <title>.</dd>
<dt>NOHEADER="true"</dt>
<dd>Enlève l'en-tête initial de la page. Un en-tête spécial
peut, bien entendu, être inclus dans le corps.</dd>
<dt>NOMIRRORS="true"</dt>
<dd>Enlève la liste des miroirs de la page. Il n'est
généralement pas recommandé de l'utiliser, à part pour quelques
pages.</dd>
<dt>NOHOMELINK="true"</dt>
<dd>Enlève le lien en bas de la page qui permet de revenir
à la page Debian principale.</dd>
<dt>NOLANGUAGES="true"</dt>
<dd>Enlève les liens en bas de la page vers les versions dans
d'autres langues.</dd>
<dt>GEN_TIME="true"</dt>
<dd>Met dans le fichier résultat la date de génération du
fichier au lieu de la date de modification du fichier source.</dd>
<dt>NOCOPYRIGHT="true"</dt>
<dd>Enlève la note de copyright en bas de la page.</dd>
</dl>
<p>Notez que vous pouvez utiliser n'importe quelle chaîne de caractères
dans ces variables : <q>true</q>, <q>yes</q>, <q>foo</q>, cela ne
change rien.</p>
<p>Un exemple d'utilisation de tout cela se trouve dans les pages sur
les portages qui ont leurs propres en-têtes ;
<code>ports/arm/index.wml</code> utilise :</p>
<pre><protect>
#use wml::debian::template title="Portage ARM" NOHEADER="yes"
</protect></pre>
<p>Si vous voulez faire quelque chose qui ne peut être fait en utilisant
les modèles existants, envisagez d'abord d'étendre l'un d'entre eux.
S'il n'est pas possible d'étendre l'un d'eux d'une manière compatible
avec l'existant, essayez de vous arranger pour que le nouveau modèle
soit un surensemble d'un modèle existant de façon à ce que les pages
puissent être converties à lui lors du passage à la prochaine version
majeure (avec un peu de chance jamais plus de tous les 6 mois).</p>
<p>Si vous créez une page qui est générée par un script ou qui contient
peu de texte, envisagez d'utiliser les balises <gettext> pour
faciliter la maintenance des traductions.</p>
<toc-add-entry name="inclusion">Inclusion d'autres fichiers</toc-add-entry>
<p>Si vous voulez séparer certaines parties de votre page dans un
fichier distinct (qui sera alors inclus dans votre fichier principal),
utilisez l'extension <code>.src</code> si votre fichier contient un
contenu qui doit être traduit ; votre fichier inclus sera alors suivi
pour les changements comme un fichier <code>.wml</code> ordinaire. Si
vous utilisez une autre extension, comme <code>.inc</code>, les
traducteurs ne remarqueront pas vos mises à jour et il se peut que
différentes langues fournissent des contenus différents.</p>
<toc-add-entry name="newdir">Ajouter un nouveau répertoire</toc-add-entry>
<p>Note : <strong>ne pas</strong> créer de répertoire ayant pour nom
<code>install</code>. Cela dérange <code>make</code> et les pages de ce
répertoire ne seront pas mises à jour automatiquement.</p>
<p>Ci-dessous se trouve un exemple d'ajout de nouveau répertoire au site
web.</p>
<pre>
mkdir foo
git add foo
cd foo
cp ../intro/Makefile .
git add Makefile
</pre>
<p>�ditez le Makefile dans le répertoire parent et ajoutez le répertoire
que vous venez de créer à la variable <code>SUBS</code>. Cela ajoutera
ce répertoire lors de la prochaine compilation quand make est lancé.</p>
<p>Enfin, enregistrez tous les changements effectués avec</p>
<pre>
git commit Makefile foo
</pre>