programminghistorian
Compter et exploiter ses données de recherche avec Unix
Programming Historian en français a reçu une proposition de traduction de la leçon Counting and mining research data with Unix de la part de Julie Zeisser (@jzeisser). La proposition a été examinée par l'équipe francophone. Nous avons discuté de cette proposition en équipe, et avons décidé de l'accepter car elle répond à nos objectifs en termes de :
- Ouverture : nous préconisons l'utilisation de logiciels libres, de langages de programmation libres et d'ensembles de données libres.
- Accès global : nous servons un lectorat travaillant avec différents systèmes d'exploitation et diverses ressources informatiques.
- Multilinguisme : nous célébrons les méthodologies et les outils qui peuvent être appliqués ou adaptés pour être utilisés dans des contextes de recherche multilingues.
- Pérennité : nous nous engageons à publier des ressources d'apprentissage qui peuvent rester utiles au-delà des interfaces graphiques actuelles et des versions actuelles des logiciels.
La traductrice s'engage à nous envoyer sa traduction dans un délai de trois mois, donc d'ici fin mars 2025 au plus tard.
Le Programming Historian en français a reçu la traduction de Counting and mining research data with Unix de Julie Zeisser (@jzeisser).
J'assume le rôle de rédacteur en charge du suivi du processus de l'évaluation. Après mon retour, l'évaluation de cette traduction sera réalisée par Raphaelle Krummeich (@Madouck) et Aymeric Luneau (@luneauaymeric).
Les relecteurs et relectrices peuvent utiliser la numérotation des lignes fournie dans l'aperçu pour organiser leurs commentaires, si cela leur convient, tout en restant libres de présenter leur évaluation de la manière qui leur semble la meilleure.
Tout membre de la communauté peut faire un retour constructif sur ce fil de commentaires, après avoir pris connaissance de nos consignes aux évaluateurs et évaluatrices et accepté notre politique contre le harcèlement (voir ci-dessous). Nous demandons que toutes les relectures cessent après réception de la seconde évaluation formelle, pour que la traductrice puisse travailler sur la révision de son texte. Le rédacteur ou la rédactrice l'annoncera sur ce fil quand cette étape aura été atteinte.
La discussion s'organise au niveau de Github. Si quelqu'un préfère de discuter de manière privée, merci de m'envoyer un message électronique. Vous avez toujours la possibilité de vous tourner vers notre médiatrice Hélène Huet si vous avez le sentiment qu'une médiation est nécessaire. Ceci ne risque d'avoir aucune incidence négative sur l'évaluation de cette leçon.
Politique contre le harcèlement
Vous trouverez ci-dessous les principes du Programming Historian en français qui doivent inspirer les échanges entre évaluateurs et évaluatrices, autrices et auteurs, rédacteurs et rédactrices, ainsi que toute personne contribuant à nos forums publics.
Le Programming Historian en français tient à garantir un environnement académique ouvert à la communauté, qui offre la pleine liberté d’explorer minutieusement des idées, poser des questions, faire des suggestions ou demander des clarifications. Il fournit aussi un espace libre de toute discrimination envers les personnes contribuant au projet indépendamment du genre, de l’orientation sexuelle, des situations d’handicap, de l’apparence physique, de la masse corporelle, de l’origine, de l’âge, de la religion ou de l’expérience technique. Nous ne tolérons aucune forme d’harcèlement ou d’attaque personnelle contre les membres de la communauté. Les personnes qui violent ces règles sont susceptibles d’être expulsées de la communauté à la discrétion du conseil éditorial. Toute personne en mesure de témoigner de tels comportements ou qui en est la victime peut contacter notre dispositif de médiation (Hélène Huet). Merci de nous aider à créer un espace d’échange et de discussion sûr.
Bonjour @emilienschultz et @jzeisser,
Vous trouverez les fichiers ici :
- .md: /fr/en-cours/traductions/compter-exploiter-donnees-unix.md
- images: [aucunes]
- assets: [aucun]
Vous pouvez parcourir l’aperçu de la soumission ici :
Bonjour Julie @jzeisser,
What's happening now?
Your lesson has been moved to the next phase of our workflow which is Phase 2: Initial Edit.
In this phase, your editor Émilien @emilienschultz will read your translation, and provide some initial feedback. Émilien will post feedback and suggestions as a comment in this issue, so that you can revise your draft in the following phase (Phase 3: Revision (1)).
%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'themeVariables': {
'cScale0': '#444444', 'cScaleLabel0': '#ffffff',
'cScale1': '#3d7c81', 'cScaleLabel1': '#ffffff',
'cScale2': '#444444', 'cScaleLabel2': '#ffffff'
} } }%%
timeline
Section Phase 1 <br> Submission
Who worked on this? : Publishing Assistant (@charlottejmc)
All Phase 1 tasks completed? : Yes
Section Phase 2 <br> Initial Edit
Who's working on this? : Editor (@emilienschultz)
Expected completion date? : 2 March
Section Phase 3 <br> Revision (1)
Who's responsible? : Translator (@jzeisser)
Expected timeframe? : ~30 days after feedback is received
Note: The Mermaid diagram above may not render on GitHub mobile. Please check in via desktop when you have a moment.
@jzeisser merci pour cette traduction, très claire. J'ai fait une première relecture et voici un retour sur quelques petits points que je trouverai intéressant à modifier
- Sur les chemins windows : remplacer directement les chemins dans la leçon, et modifier l'encart dans ce sens pour dire que cela a été modifié ?
- Toujours mettre "chaînes de caractères" plutôt que "chaînes" tout court
- Je suggère de mettre les mentions de formats comme .zip ou .tsv entre ticks `` pour faciliter la lecture
- De privilégier les guillemets françaises plutôt que "“"
Sur les paragraphes :
P4 : "des données de recherche" -> "les données de la recherche" / "des données en recherche" (de manière générale, je m'interroge sans avoir de réponse sur la meilleure version, sachant que là il y a plusieurs versions utilisées, par p7 "vos données de la recherche" -> "vos données de recherche") p6 : le terme révolutionner me semble un peu fort pour transform, mais c'est juste une réflexion p8 manque une parenthèse pour le lien p10: "Cette leçon a été créée avec Git Bash 1.9.0" -> "Cette leçon a été écrite avec Git Bash 1.9.0" ? P28 typo pour "ous permets"
Je vous laisse intégrer et faire un retour, avant de continuer dans le processus d'évaluation
Bonjour @charlottejmc et @emilienschultz, et merci pour toutes ces précisions sur votre processus éditorial. J'ai pris bonne note des dates et délais mentionnés dans le graphique. Au plaisir de lire vos retours et suggestions.
J'en profite pour ajouter dans la discussion ici des points qui ont été mentionnés en échange de mail que @jzeisser a proposé pour la traduction
- l'encart qui signale un changement dans les chemins de fichier sous windows
- un ajout de références en plus pour le lectorat français
Bonjour @emilienschultz,
Nos messages se sont croisés... Je vous remercie pour ce retour très constructif. Je vous réponds rapidement :
- je me suis fait la même réflexion ce matin pour les chemins Windows, je pense qu'il vaut effectivement mieux procéder dans ce sens ;
- bonne remarque pour les "chaînes de caractères" ;
- c'est noté pour les ticks et l'usage des guillemets chevrons, je corrige.
P8 et 28 : merci pour le signalement de ces coquilles, je corrige
P4 : concernant la traduction de "research data", vous mettez le doigt sur un problème que je n'ai pas vraiment réglé. Mes recherches terminologiques ne m'ont pas permis de dégager une prévalence claire d'une expression ou d'une autre en français pour traduire l'expression, et c'est pour cela que j'ai beaucoup hésité. Je me range donc à votre avis de traduire par "les données de la recherche" et veillerai à uniformiser.
P6 : "révolutionner" est effectivement un peu fort. J'ai privilégié ici le naturel et la fluidité du français par rapport au sens. "changer" me paraît trop faible et pas forcément très naturel, quant aux mots de sens proche comme "transformer" ou "métamorphoser", je les trouve carrément maladroits dans la phrase. Je vais continuer à réfléchir à cette question.
P10 : je trouve pour ma part que remplacer "créée" par "écrite" ici introduit une confusion, car on pourrait comprendre que l'on parle du processus de rédaction de la leçon et pas du logiciel utilisé dans la leçon. Je ne comprends d'ailleurs pas très bien la raison de votre préférence pour "écrire" ici... que pensez-vous de "conçue" ?
Super. Merci pour votre réponse rapide.
Pour les deux remarques sur "transformer" et "créer" je suis d'accord avec vous, c'était davantage exprimer une réflexion qu'un avis fort de ma part.
Bonjour @jzeisser et @emilienschultz,
Ravie de lire votre échange. Anisa et moi sommes du même avis à propos du chemin c/Users/NOM_UTILISATEUR/proghist/ : il vaut mieux le changer directement. Même pas besoin non plus de laisser un mot aux lecteur·ices, car nous allons mettre à jour la leçon originale.
Bonjour @jzeisser,
What's happening now?
Your lesson has been moved to the next phase of our workflow which is Phase 3: First Revision.
This phase is an opportunity for you to revise your draft in response to @emilienschultz's initial feedback.
@anisa-hawes will send you an invitation to join us as an Outside Collaborator here on GitHub. This will give you the 'write access' you'll need to edit your lesson directly.
We ask authors to work on their own files with direct commits: we prefer you don't fork our repo, or use the Pull Request system to edit in ph-submissions. You can make direct commits to your file here: /fr/en-cours/originales/compter-exploiter-donnees-unix.md. Anisa and I can help if you encounter any practical problems!
When you and Émilien are both happy with the revised draft, we will move forward to Phase 4: Open Peer Review.
%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'themeVariables': {
'cScale0': '#444444', 'cScaleLabel0': '#ffffff',
'cScale1': '#3d7c81', 'cScaleLabel1': '#ffffff',
'cScale2': '#444444', 'cScaleLabel2': '#ffffff'
} } }%%
timeline
Section Phase 2 <br> Initial Edit
Who worked on this? : Editor (@emilienschultz)
All Phase 2 tasks completed? : Yes
Section Phase 3 <br> First Revision
Who's working on this? : Author (@jzeisser)
Expected completion date? : 02 May
Section Phase 4 <br> Open Peer Review
Who's responsible? : Reviewers (TBC)
Expected timeframe? : ~60 days after request is accepted
Note: The Mermaid diagram above may not render on GitHub mobile. Please check in via desktop when you have a moment.
Bonjour Julie @jzeisser,
I have sent you an invitation to join us as an Outside Collaborator - you'll find this in your inbox of the email associated with your GitHub account.
When you've accepted this invitation you'll be able to begin making revisions to your lesson: /fr/en-cours/originales/compter-exploiter-donnees-unix.md.
Please let Charlotte or I know if you have any questions ☺
Bonjour @charlottejmc et @anisa-hawes,
Thanks a lot for your warm messages and for all the additional info!
I only have one question, just to make sure I understood your instructions: I should use the "Edit file in place" function to revise my lesson instead of GitHub's push-pull request system, right?
Bonjour @emilienschultz,
J'ai terminé la première révision de ma traduction et appliqué tous les changements dont nous avons discuté plus haut, en gardant quand même «révolutionner» (je continue de réfléchir à une autre façon de tourner la phrase).
Évidemment, je n'ai pas pu m'empêcher d'en profiter pour effectuer quelques autres petites modifications de style, notamment sur : «les historiens et les historiennes peuvent avoir besoin de les réutiliser» (le pluriel est plus naturel que le singulier ici) «définir des normes pour nommer vos fichiers de manière cohérente et prévisible» («nommage» m'a choquée à la relecture)
Comme j'ai supprimé l'encart d'avertissement et corrigé tous les chemins Windows, je me suis permis d'ajouter «, et ceux correspondant à Windows ont été mis à jour pour une utilisation avec Git Bash 2.49.0.» au paragraphe 3 de «Logiciel et configuration». Je n'ai pas osé supprimer la phrase précédente sur la conception de la leçon, ne sachant pas comment le texte source va être mis à jour. Peut-être faudra-t-il réadapter une fois que la nouvelle version anglaise sera publiée ?
Merci @jzeisser, j'ai fait une très légère modification à propos des chemins Windows, mais ça me parait bien exprimé ! La version anglaise a été mise à jour comme ceci.
Just une questions : je voulais m'assurer que les chemins Windows utilisent bien dorénavant des "forward slash" plutôt que des "backslash" ?
Merci beaucoup, @charlottejmc , c'est parfait ! Et merci pour le lien vers la version mise à jour. Je garde donc la phrase, puisqu'elle reste dans la leçon originale.
Oui, les chemins Windows utilisent bien les slash et pas les anti-slash... sur cette nouvelle version de Git, en tout cas. Powershell continue, par contre, d'utiliser les anti-slash.
C'est bon pour moi, @charlottejmc est-ce le moment de passer à l'étape suivante d'open peer review ?
Bonjour @jzeisser,
What's happening now?
Your lesson has been moved to the next phase of our workflow which is Phase 4: Open Peer Review.
This phase is an opportunity for you to hear feedback from peers in the community.
Émilien @emilienschultz has invited two reviewers to read your lesson/translation, test your code, and provide constructive feedback. In the spirit of openness, reviews will be posted as comments in this issue (unless you specifically request a closed review).
After both reviews, Émilien will summarise the suggestions to clarify your priorities in Phase 5: Second Revision.
%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'themeVariables': {
'cScale0': '#444444', 'cScaleLabel0': '#ffffff',
'cScale1': '#3d7c81', 'cScaleLabel1': '#ffffff',
'cScale2': '#444444', 'cScaleLabel2': '#ffffff'
} } }%%
timeline
Section Phase 3 <br> First Revision
Who worked on this? : Author (@jzeisser)
All Phase 3 tasks completed? : Yes
Section Phase 4 <br> Open Peer Review
Who's working on this? : Reviewers
Expected completion date? : 9 June
Section Phase 5 <br> Second Revision
Who's responsible? : Author (@jzeisser)
Expected timeframe? : ~30 days after editor's summary
Note: The Mermaid diagram above may not render on GitHub mobile. Please check in via desktop when you have a moment.
Evaluation ouverte par les pairs
Au cours des phases 2 et 3, j'ai pu donner un premier retour sur cette leçon / traduction, puis j'ai collaboré avec @jzeisser pour effectuer une première série de révisions.
Lors de la Phase 4 : évaluation ouverte par les pairs, nous invitons d'autres membres de notre communauté à nous faire part de leurs commentaires.
Bienvenue à Raphaelle Krummeich (@Madouck) et Aymeric Luneau (@luneauaymeric). En participant à ce processus d'évaluation par les pairs, vous contribuez à la création d'une ressource technique utile et durable pour l'ensemble de la communauté. Merci.
Veuillez lire la traduction, tester le code et publier votre évaluation sous forme de commentaire dans ce ticket avant le 19 mai 2025
Consignes aux évaluateurs et évaluatrices:
L’aperçu de la leçon:
- <http://programminghistorian.github.io/ph-submissions/fr/en-cours/traductions/compter-exploiter-donnees-unix >
-- Notes:
- Nous recommandons à tous les participants à cette discussion de lire et suivre notre Code de Conduite.
- Les membres de la communauté au sens large peuvent également choisir de soumettre une évaluation.
- Tous les participants doivent adhérer à notre politique contre le harcèlement :
Politique contre le harcèlement
Vous trouverez ci-dessous les principes du Programming Historian en français qui doivent inspirer les échanges entre évaluateurs et évaluatrices, auteur(e)s, rédacteurs et rédactrices, ainsi que toute personne contribuant à nos forums publics.
Programming Historian en français tient à garantir un environnement académique ouvert à la communauté, qui offre la pleine liberté d’explorer minutieusement des idées, poser des questions, faire des suggestions ou demander des clarifications. Il fournit aussi un espace libre de toute discrimination envers les personnes contribuant au projet, indépendamment du genre, de l’orientation sexuelle, des situations d’handicap, de l’apparence physique, de la masse corporelle, de l’origine, de l’âge, de la religion ou de l’expérience technique. Nous ne tolérons aucune forme de harcèlement ou d’attaque personnelle contre les membres de la communauté. Les personnes qui violent ces règles sont susceptibles d’être expulsées de la communauté à la discrétion du conseil éditorial. Toute personne en mesure de témoigner de tels comportements ou qui en est la victime peut contacter notre médiatrice Hélène Huet. Merci de nous aider à créer un espace d’échange et de discussion sûr.
Bonjour, j'ai fait une première relecture et j'ai maintenant des questions de clarification sur la manière de procéder et d'évaluer:
- Où devons-nous écrire les commentaires ou les propositions de révision ? Je crois que c'est une information qui nous a été donnée mais je ne la retrouve pas.
- On est d'accord qu'on évalue uniquement la qualité de la traduction, pas le contenu de la leçon en tant que tel ?
Bonjour Aymeric @luneauaymeric,
We invite you to post your comments and suggestions here in the issue, so that reviews and discussions can develop in an open exchange.
Our CC-BY open licence invites and encourages adaptation for new audiences, so if there are adjustments you'd like to suggest to the content or structure of the translation, these are welcomed.
Equally, if you encountered any technical errors while testing this lesson, we can update the original lesson with your suggested changes as a maintenance issue.
With our thanks.
Bonjour @luneauaymeric , oui, écrivez-vos commentaires ici ! Vous pouvez faire référence aux paragraphes de la prévisualisation, ou bien aux lignes du fichier .md, en fonction de ce que vous préférez, pour situer vos remarques (un exemple ici, cliquer sur "load more" pour voir les échanges). Et comme @anisa-hawes l'a précisé, vous pouvez suggérer des améliorations si vous constatez des soucis avec le contenu.
Bonjour,
je commence ici ma révision avec des propositions concernant uniquement l'introduction:
- La première phrase du paragraphe 4 (ci-après : §1, §2... §n) me semble un peu "lourde", notamment si on compare à la version originale. Il me semble qu'on peut être un peu plus direct. Exemple:
"Cette leçon montre comment décompter et explorer les données de la recherche grâce au shell Unix Bash, lorsqu’elles sont classées de manière claire et prévisible."
Ou "Cette leçon montre comment les données de la recherche, lorsqu’elles sont classées de manière claire et prévisible, peuvent être décomptés et explorées grâce au shell Unix Bash"
- §5, l1 : projet de recherche spécifique à la place de projet de recherche en particulier
- §6, l2 : je trouve la formulation "vos données de la recherche" un peu bizarre. Mais ça suppose de rouvrir le débat sur "données de la recherche", "données de recherche". Est-ce que ça ne suffit pas de parler de "données" tout simplement ?
- §6, l3-5: là aussi je pense que le style peut être plus directe. Plutôt que "vous permettra de vous familiariser", on peut écrire "vous familliarisera".
- §6, dernière ligne : pour éviter la répétition on peut remplacer "utiliser" par "appliquer à des données non tabulaires"
- $7 : propositions pour alléger le style
Cette leçon vous montrera aussi que, bien souvent, la possibilité de manipuler, de décompter et d'explorervos données dépendent tout autant de la quantité de métadonnées, c’est-à-dire le texte descriptif, contenue dans les noms des fichiers exploités que des commandes Unix que vous aurez appris à utiliser.
Ainsi, bien que ce ne soit pas un prérequis pour travailler avec le shell Unix, prendre le temps d’organiser vos données de la recherche et de nommer vos fichiers selon des normes cohérentes et prévisibles est indéniablement une étape cruciale pour tirer tous les bénéfices des commandes Unix et exploiter au mieux les données de la recherche.
Décompte des fichiers
- §22 : je ne comprends pas la dernière phrase. Cela veut dire que la commande
wc -w <nom_du_fichier>additionne le nombre de mots dans le fichier et dans le nom du fichier ? - §26: pourquoi ce conseil ?
Explorer les fichiers
§39 : je ne parviens pas à reproduire le resultat de la commande grep -iv revolution 2014*_JA_a*.tsv > 2014_JA_iv_revolution.csv. Malgré l'extension .csv, les données reste séparés par des tabulations et non des virgules. Est-ce normal ? (je précise que je travaille sur une distribution debian 12).
Peut-on envisager une illustration pour comprendre quelles différences on doit observer ?
Conclusion
Pas de remarque
Merci @luneauaymeric ; je vais attendre les retours de @Madouck et ensuite synthétiser les retours pour une révision.
Merci @luneauaymeric ; je vais attendre les retours de @Madouck et ensuite synthétiser les retours pour une révision.
je pense fournir une réponse détaillée dans la journée du 15 mai :)
Bonjour @luneauaymeric,
Je vous remercie pour vos retours circonstanciés. J'attends ceux de @Madouck pour me pencher sur les modifications sur la forme, mais je voudrais déjà répondre à vos questions de fond.
Décompte des fichiers
- §22 : je ne comprends pas la dernière phrase. Cela veut dire que la commande
wc -w <nom_du_fichier>additionne le nombre de mots dans le fichier et dans le nom du fichier ?
Non, cela signifie que "wc" est la commande générale pour compter (des mots, des bytes, des lignes, etc.) et que l'option "-w", "-c", "-l" vient préciser justement ce que l'on veut compter (respectivement, les mots, les bytes et les lignes). Si l'on décompose la commande que vous citez, wc -w <nom_du_fichier>, nous avons donc, dans l'ordre : "imprimer un décompte" "de mots" "contenus dans le fichier X". Le résultat que vous obtenez ensuite indique un chiffre qui correspond au nombre de mots + fichier X.
- §26: pourquoi ce conseil ?
Ce n'est pas le mien, c'est celui de l'auteur, mais je crois pouvoir l'expliquer en partie.
L'option -c, de la commande wc dans bash, correspond en fait aux bytes, pas aux caractères.
Avec
wc -c vous comptez le nombre de bytes que contient un fichier. Le résultat s'avère identique au nombre de caractères en fonction de l'encodage de caractères de votre système (1 bytes = 8 bits, souvent = 1 caractère, mais pas toujours).
C'est donc un peu "par hasard" que les nombres de caractères et de bytes sont égaux, cela peut varier. La "vraie" commande pour compter les caractères dans bash, c'est bien
wc -m.
Mais j'ai l'impression que c'est le cas aussi bien sous Linux que sous Windows (j'ai testé dans les deux environnements). Je ne sais pas exactement ce qui a poussé l'auteur à donner cette recommandation uniquement pour les systèmes Linux et Mac puisqu'il me semble que c'est la même chose sous Windows. Peut-être que l'ancienne version de Git Bash pour Windows fonctionnait différemment ? Quoi qu'il en soit, j'ai préféré ne pas retirer cette information, car cela dépasse mon rôle de traductrice.
[Edit:] A la réflexion, je me demande si l'auteur n'a pas souhaité simplifier en présentant l'option -c comme le décompte de caractères sur Windows à cause de la commande présentée au §32 : grep -c pour compter les occurrences d'une même chaîne de caractères. Si vous remplacez par grep -m sur Windows, la commande ne donne aucun résultat, et sur Linux vous obtenez le total de toutes les occurrences séparées d'au moins l'un des caractères...
Explorer les fichiers
§39 : je ne parviens pas à reproduire le resultat de la commande
grep -iv revolution 2014*_JA_a*.tsv > 2014_JA_iv_revolution.csv. Malgré l'extension.csv, les données reste séparés par des tabulations et non des virgules. Est-ce normal ? (je précise que je travaille sur une distribution debian 12).
Je ne comprends pas ce que vous n'arrivez pas à reproduire exactement : est-ce que la commande vous indique une erreur ? est-ce que vous n'obtenez pas de fichier .csv en sortie ? ou est-ce que vous ne constatez aucune différence entre le fichier .tsv et .csv ?
Si vous vous trouvez dans ce dernier cas de figure, c'est tout à fait normal si vous utilisez Debian. LibreOffice Calc (et peut-être d'autres logiciels, mais je suppose que vous utilisez celui-ci) récupère le décalage que l'on constate effectivement dans Microsoft Excel. Il n'y a aucune différence entre les deux fichiers ouverts dans LO Calc, par contre les colonnes qui s'affichent dans MS Excel sont effectivement complètement différentes entre le .tsv et le .csv. C'est pour cela que j'ai ajouté la précision en fin de paragraphe : "En revanche, certains programmes sont plus habiles à rattraper cette perte de données et il se peut que vous ne voyiez aucune différence si vous utilisez un autre logiciel, comme LibreOffice Calc, ou un autre système, comme Linux ou macOS." Je n'ai pas voulu paraître péremptoire en affirmant que sous Linux vous ne verrez aucune différence, puisque je n'ai pas testé dans toutes les distributions ni avec tous les logiciels de tableur disponibles... mais ma phrase n'est peut-être pas suffisamment assertive si vous n'avez pas relevé la précision ?