[fichiers de configuration]Idée de traduire

[reflets de vert]

Bonjour à tous,

J'en ai parlé avec quelques personnes, quand on discutait d'archlinux.

Comme il y a beaucoup de commentaires dans les fichiers de configuration, qui sont utiles et bien faits (ça dépend des fichiers), que parfois on rajoute ses propres commentaires (pour prêter un ordi à quelqu'un j'ai même traduit une partie du texte affiché au démarrage dans sysinit.rc), je me disais que du coup ça ne serait pas plus intéressant de tous les traduire en français, et de rajouter des commentaires inédits (tant qu'à traduire, et puis ce serait vraiment intéressant d'étoffer à certains endroits).

Le travail est assez lourd, mais ce n'est que de la traduction.
Je n'ai aucune idée de comment ce serait faisable, mais je pose la question à tout le monde.

[farvardin]

ça me semble un travail de titan, en plus cela obligerait à avoir les versions sur un autre serveur, et comment ça se passe lors des mises à jour ?

[tuxce]

Les pages de man sont normalement fait pour ça.
Traduire les fichiers de conf demande de forker le soft vu que pour la plupart, il n'est pas prévu de fichier de conf spécifique à une localisation.

[FoolEcho]

Je ne suis pas persuadé de l'intérêt. Je développe:

mais ce n'est que de la traduction

et de rajouter des commentaires inédits (tant qu'à traduire, et puis ce serait vraiment intéressant d'étoffer à certains endroits).

Tu proposes plus "que" de la traduction (je trouve ça un peu péjoratif, d'ailleurs, traduire précisément sans polluer le sens n'a rien d'aisé) et c'est très dangereux: d'une part, le traducteur peut altérer certains passages originaux (oui, oui, c'est pas de la grande littérature, mais ce n'est pas une raison -- d'autant moins quand ça touche à des sujets sensibles), d'autre part les parties "à étoffer" seront assez subjectives selon le degré de connaissance (et un bon commentaire et un commentaire qui ne se perd pas dans les détails... à l'inverse de mes propos ).

Internationaliser les fichiers de conf représenterait un boulot titanesque, dans sa mise en place et dans son maintien pour un intérêt somme toute assez restreint. Comme évoqué au dessus, c'est tout l'intérêt de 'man'. Et quitte à mettre les mains dans le cambuis par la suite, autant avoir la version originale des commentaires.

Ou alors, sur le modèle qui existe déjà, il faut concevoir davantage d'applications, qui elles peuvent être localisées, pour interagir avec les fichiers de configuration, à la manière d'Ubuntu ou de Mandriva. Mais forcément du coup, on perd de vue la base de l'édifice (et le charme d'Arch) et on se sent impuissant dès que le serveur graphique ou le bureau a une défaillance.

Ce que tu proposes à mon avis ressemble davantage à la traduction de bons tutos pour exploiter au mieux les fichiers de configuration plutôt que leur reformatage. Cela semble moins "glorieux" mais c'est nettement plus utile et davantage dans le domaine du faisable à court/moyen terme.

[bennyboy]

Si tu le fais en tout les cas, stp n'ajoute pas de la francisation à outrance, je trouve <avis_perso> que ça devient souvent ridicule et incompréhensible, et qui plus est, n'aide pas vraiment le end user puisque pour trouver plus de détails il faudra bien souvent se tourner vers l'anglais et donc retrouver l'équivalent des termes.</avis_perso>

Ce n'est que mon avis mais je pense sincérement qu'il existe assez de traducteurs en ligne pour pouvoir traduire les phrases incomprises dans un commentaire d'un fichier de conf. Perso je parle quotidiennement l'anglais mais je préfère malgré tout lire un bon tutorial en français dans un premier temps pour avoir les bases dans ma langue maternelle, et ensuite me tourner vers l'anglais pour approfondir, une fois les bases acquises.

Je trouve donc que le concept de traduire le wiki est génial parce que il te donne tout pour pouvoir te lancer

[reflets de vert]

J'aime pas trop l'idée de mettre tout dans des fenêtres, c'est sûr. Tout automatiser ça a pas mal d'inconvénients, ça crée plein de programmes qui se lancent au démarrage et qui sont pas réellement utiles.
En commencant à utiliser archlinux je me suis dit que c'est pas forcément si difficile tout ça, et que c'est le wiki, le forum, les commentaires et toutes les infos qui tournent autour qui aident.

Traduire des tutos c'est une bonne chose, je ne sais pas ce qui est en cours ou autre j'avoue que bon… je n'ai pas regardé.

Je n'ai pas une très bonne connaissance des fichiers de configuration, mais cette idée de traduction est intéressante pour donner un accès direct et hors connexion aux fichiers de configuration.

J'ai tapé man /etc/rc.conf pour voir, et effectivement il y a une page de manuel (bon je me suis rendu compte qu'elle est en anglais, j'ai ensuite cherché, ajouté le dépot, mais… bon j'en parle dans un autre fil).

Cette page de manuel semble reprendre l'ensemble du fichier, comme si il était lu par un éditeur de texte en mode lecture seule.
Je ne sais pas comment elle marche, et du coup je n'ai pas pu voir sa version française.
En effet ce serait une bonne solution de traduire les pages man pour les fichiers de configuration, cela laisserait les commentaires originaux, mais cela pose la question de ce qui "doit", ou peut y être mis.

Je préférerais l'idée de traduire "strictement" (on laisse les versions anglaises à côté de la traduction en cas de doute) au niveau de pages man des fichiers de configuration les commentaires tout en rajoutant (l'idée est de faire des rajouts plutôt que de modifier l'ensemble) des commentaires inédits qui reprendraient certains éléments du wiki, qui ajouteraient des infos courtes, expliquerait des fonctionnements, préviendrait de certaines erreurs courantes (à la manière de /etc/sudoers qui prévient du risque de ne pas utiliser visudo), etc...

Bien sûr il y a déjà le wiki, des tutoriaux… donc ces pages man devraient être complémentaires d'une manière ou d'une autre, et plus se focaliser sur les réglages contenus dans les fichiers de configuration en eux-mêmes, expliquer les syntaxes, etc…

La question de l'intérêt de tout ça se pose si les mises à jour obligent de constamment tout changer. Mais ce n'est pas évident non plus au niveau des documentations pour des mises à jour comme celle récente de xorg.

Je mets des exemples, pour que mon idée de page man soit mieux comprise (bon pas aboutis les exemples):

Pour etc/pacman.d/mirrorlist

Code : Tout sélectionner

#
# Arch Linux repository mirrorlist
#Liste des dépôts miroir d'Archlinux
#
#Ce fichier de configuration permet à pacman de savoir au niveau de quels serveurs chercher ses informations (paquets, etc…)
#Les serveurs décommentés sont pris en compte par pacman dans l'ordre d'apparition du texte

pour /etc/group:

Code : Tout sélectionner

#Liste des groupes et de leurs membres.
#Les numéros des groupes sont écrits après "::" ou "x:", les membres sont listés
#

pour /etc/passwd:

Code : Tout sélectionner

#Liste des utilisateurs, avec leur numéro d'identification, et des caractéristiques importantes

(bon ce dernier est vraiment pas terrible, mais c'est pour l'idée)

C'est un peu maladroit tout ça, je ne suis pas absolument sûr, et (je ne l'ai pas dit avant) cela reflète mon opinion provisoire

[FoolEcho]

J'ai tapé man /etc/rc.conf pour voir, et effectivement il y a une page de manuel (bon je me suis rendu compte qu'elle est en anglais, j'ai ensuite cherché, ajouté le dépot, mais… bon j'en parle dans un autre fil).

Cette page de manuel semble reprendre l'ensemble du fichier, comme si il était lu par un éditeur de texte en mode lecture seule.

C'est le cas en effet car rc.conf n'est en fait pas documenté ( je jetterai un oeil à ton autre fil ).
S'il l'était,

Code : Tout sélectionner

man rc.conf

serait suffisant.

Pour etc/pacman.d/mirrorlist

En fait, tu l'as déjà indirectement... Via

Code : Tout sélectionner

man pacman

, dans l'une des sections:

Code : Tout sélectionner

CONFIGURATION
       See pacman.conf(5) for more details on configuring pacman using the
       pacman.conf file.

Puis

Code : Tout sélectionner

man pacman.conf

, dans une autre section:

Code : Tout sélectionner

REPOSITORY SECTIONS
       Each repository section defines a section name and at least one location where
       the packages can be found. The section name is defined by the string within
       square brackets (the two above are current and custom). Locations are defined
       with the Server directive and follow a URL naming structure. If you want to
       use a local directory, you can specify the full path with a “file://” prefix,
       as shown above.

       A common way to define DB locations utilizes the Include directive. For each
       repository defined in the configuration file, a single Include directive can
       contain a file that lists the servers for that repository.

           [core]
           # use this repository first
           Server = ftp://ftp.archlinux.org/core/os/arch
           # next use servers as defined in the mirrorlist below
           Include = /etc/pacman.d/mirrorlist

       During parsing, pacman will define the $repo variable to the name of the
       current section. This is often utilized in files specified using the Include
       directive so all repositories can use the same mirrorfile. pacman also defines
       the $arch variable to the value of Architecture, so the same mirrorfile can
       even be used for different architectures.

           Server = ftp://ftp.archlinux.org/$repo/os/$arch

       The order of repositories in the configuration files matters; repositories
       listed first will take precedence over those listed later in the file when
       packages in two repositories have identical names, regardless of version
       number.

De même pour les autres.

Tu comprends pourquoi (à mon avis) peu seront enclin à te suivre alors que (presque) tout est là.
Mais je te rejoins sur l'effort effectivement à faire, à savoir que tout le manuel n'a pas forcément de version localisée (fait un "man man" et tu verras une belle version française). Cf. les exemples du dessus.

[reflets de vert]

Ok d'accord, c'est en effet plus clair.

Je ne me suis pas assez posé la question; je me servais de man plus pour les programmes.

Quand on tape man group on a quelque chose sur le fichier de configuration. Quand on tape man /etc/group on a le fichier en lui même.
Bon ne rigolez pas je teste.

Pour mirrorlist ce serait une bonne idée que man mirrorlist fasse une redirection vers les pages qui parlent directement ou indirectement de /etc/pacman.d/mirrorlist, de sorte que la commande man mirrorlist donne une page qui liste les différentes entrées. (je sais quand j'ai une idée… mais c'est l'idée de donner accès à des man pour tous les fichiers de configuration, quitte à rediriger vers l'existant).

Ajouter des entrées pour man rc.conf ou autre serait intéressant.

Je vois que l'existant est assez solide et fiable. Mais peut-être quelques rajouts ou adaptations, redirections…?

Pour l'idée de traduire les pages de man, c'est en effet intéressant et important.
Je ne suis pas parfait en anglais mais je préfère traduire dans le sens anglais ? français; je veux bien aider à ça avec le temps que je peux avoir.

[tuxce]

Pour mirrorlist ce serait une bonne idée que man mirrorlist fasse une redirection vers les pages qui parlent directement ou indirectement de /etc/pacman.d/mirrorlist, de sorte que la commande man mirrorlist donne une page qui liste les différentes entrées.

"mirrorlist" n'est rien du tout, il s'appellerait "toto" que ça ne changerait rien.
C'est un fichier inclut par pacman.conf et la syntaxe est celle de pacman.conf, il est là juste pour pas se taper la liste des serveurs autant de fois qu'il y a de dépôt.

Ajouter des entrées pour man rc.conf ou autre serait intéressant.

http://thread.gmane.org/gmane.linux.arch.general/30558

[reflets de vert]

Est-ce que l'idée d'avoir des entrées dans man pour tous les fichiers de configuration, quitte à faire des redirections, ne serait-pas intéressante?
C'est pas très grave d'avoir des doublons ou plus, la même chose expliquée trois fois c'est toujours trois manières différentes de comprendre.

C'est bien qu'il y ait des dicussions là-dessus chez les amis anglophones. Ca montre que l'idée a déjà été abordée.

[farvardin]

comprends bien que je déplore que la langue anglaise soit systématiquement utilisée en informatique (et ailleurs...), cela induit une dépendance culturelle pas toujours souhaitable (par exemple les gens vont faire des séjours linguistiques aux USA ou Angleterre au lieu d'aller en Russie ou en Chine...), néanmoins avant que les fichiers de config passent en esperanto, de l'eau va couler sous les ponts...

Je pense vraiment que la seule solution pour quelqu'un n'ayant pas un niveau d'anglais suffisant, c'est de consulter le wiki, par exemple pour le coup de mirrorlist on le trouve ici :
http://wiki.archlinux.fr/man/archlinux/pacman_conf

[reflets de vert]

Il faudrait les mettre en Kotava les fichiers de configuration. Au moins on sera sûr qu'il s'agira d'une super langue universelle, qui devrait d'ailleurs être adaptée à archlinux pour pouvoir fonctionner pleinement.


Plus sérieusement, j'apprécie les contraintes et l'apprentissage des langues (ça me fait penser qu'il faudrait que je me remette au chinois grmblstrtsrrr…), mais je pense que pour comprendre le fonctionnement des programmes et du système il est chouette, vraiment, d'avoir une base dans sa langue.
Après on peut aller vers les autres langues, et c'est de toute façon ce qu'on fait souvent.

Pour résumer l'idée de reflets de vert (mince maintenant il parle à la troisième personne, que va-t-il advenir de lui?), soit traduire les fichiers de configuration (à condition qu'il y ait une solution élégante avec yaourt ou autre pour faire les remplacements nécessaires), soit traduire un peu plus de pages man, créer des pages man pour tous les fichiers de configuration, et créer des redirections de man Y.conf vers Y.sh ou autre … pour éviter les redondances inutiles (mais il a dit qu'il y a aussi des redondances utiles…!)

[reflets de vert]

L'idée du wiki est chouette. Je m'en sers souvent.

Le côté d'avoir quelque chose d'intégré à man ou aux fichiers de configuration permet de travailler hors connexion… ça arrive les soucis à ce niveau…

Ou sinon httracker le wiki et le lire hors connexion avec lynx… mais je ne trouve pas que ça soit aussi simple.