rOpenSci - open tools for open science

En route pour le lancement ! Paquets expédiés au R-Multiverse

rOpenSci — Wed, 22 Oct 2025 00:00:00 +0000

Will Landau a récemment présenté le R-multiverse, une nouvelle façon de publier des paquets R lors d’une réunion de la communauté de rOpenSci¹. Après cet événement, une session coworking a permis à Will, à ses collègues administrateurs du R-multiverse Jeroen Ooms et Maëlle Salmon, ainsi qu’aux membres de la communauté, de discuter encore davantage.

Une mission clé de cette session de coworking était de soumettre des paquets au R-multiverse en direct ! À la suite de la session de instructions tout responsable de paquet souhaitant envoyer son logiciel dans le dépôt communautaire doit :

créer une “release” GitHub ou GitLab de son paquet ;
ouvrir une Pull Request au dépôt contributions GitHub, en ajoutant un fichier texte contenant l’URL du dépôt².

Will a également partagé une fonction R qui vous permet d’effectuer des vérifications de paquets R-multiverse localement avant de les soumettre : multiverse.internals::review_package().

Trois paquets ont été soumis lors de la session de coworking !

Paquets soumis

riem, pour obtenir des données météorologiques des stations ASOS (aéroports) via l’Iowa Environment Mesonet.

J’ai soumis mon paquets riem qui accède aux données météorologiques des aéroports, même s’il est également distribué sur CRAN : je voulais explorer différentes possibilités de publication. Parce que les vérifications automatiques (de la licence par exemple) ont passé et parce que je suis une membre public d’une organisation GitHub à laquelle le multivers fait confiance (ropensci), ma PR a été automatiquement fusionnée.

En savoir plus sur riem.

geotargets, qui étend targets pour travailler avec des formats de données géospatiales

Eric R. Scott a soumis le paquet geotargets qui étend le champ d’application de targets aux formats de données géospatiales, tels que les rasters et les vecteurs (par exemple, les “shapefiles”). Eric a co-écrit geotargets avec Nick Tierney et Andrew Brown, mais Nick est le principal mainteneur. Cependant, il est tout à fait acceptable qu’Eric ait soumis le paquet plutôt que Nick. En effet, R-multiverse vous permet de contribuer à des paquets que vous n’avez pas écrits du tout ³ à condition que la licence accordel’autorisation claire de distribuer et de modifier le code.

En savoir plus sur geotargets.

weathercan, pour trouver et télécharger des données météorologiques historiques d’Environnement et Changement Climatique Canada (ECCC)

Steffi LaZerte a soumis son paquet weathercan également un paquet météo mais pour le Canada ! Steffi s’est demandé s’il était judicieux de soumettre weathercan avant d’effectuer un certain nombre de corrections et d’améliorations qu’elle avait planifiées pour les semaines à venir. Il s’avère que, oui, cela a du sens ! En effet, le multivers récupère automatiquement la dernière version. Steffi doit seulement se rappeler de créer une nouvelle “release” après avoir amélioré weathercan.

En savoir plus sur weathercan.

Quelle est la suite pour ces paquets ?

Maintenant que ces paquets sont arrivés, ils sont distribués par l’intermédiaire du dépôt de communauté. Il s’agit d’une sorte d’aperçu des nouvelles versions.

Dans quelques semaines, lorsque R-multiverse commencera à construire le prochain instantané de production ils seront vérifiés en même temps que les autres paquets. S’ils sont acceptables, leur version à ce moment-là sera celle qui sera intégrée à la production. S’il y a des problèmes, le responsable peut toujours apporter des corrections.

Tant que ces paquets sont listés dans le R-multiverse, ils participeront aux snapshots de production trimestriels. Les responsables n’ont qu’à continuer à créer des “releases” (bonne pratique de toute façon) et à suivre la procédure statut de leur paquet dans R-multiverse.

Pour que les utilisateur·rice·s du paquet sachent qu’il·elle·s peuvent l’installer à partir du dépôt communauté ou du dépôt production les responsables des paquets devront mettre à jour les instructions d’installation dans le README de leur paquet. Ils peuvent également ajouter un badge.

Quelle est la suite pour le multivers R ?

Après la conférence posit, l’appel à la communauté rOpenSci et la session de coworking rOpenSci, R-multiverse vise à augmenter la participation à son système pour le renforcer et le diversifier. Les soumissions de nouveaux paquets sont les bienvenues, tout comme les questions et demandes de fonctionnalités. Vous pouvez également poser votre candidature pour devenir modérateur de paquet pour aider à gérer les nouvelles soumissions.

Et avant cela, lors d’une conférence à posit::conf ! Restez à l’écoute pour la publication des enregistrements des conférences publiques sur YouTube. ↩︎
Ou un fichier JSON un peu plus complexe si le paquet se trouve dans un sous-répertoire, par exemple. ↩︎
La liste d’auteur·rice·s du paquet reste inchangée. ↩︎

Reconnaissance au-delà des auteur·rice·s de billets de blog

rOpenSci — Tue, 14 Oct 2025 00:00:00 +0000

Read it in: English.

Read it in: Español.

Notre propre guide de développement souligne

Sois généreux·se avec les attributions

Reconnaître les diverses formes de contributions à notre mission est très importante pour nous : nous aimons remercier les personnes qui font la révision de paquets et plus généralement tous les contributeur·rice·s aux paquets, les organisations ainsi que les individus.

Nous avons récemment étendu nos efforts à la reconnaissance des différents rôles permettant la publication d’un article de blog.

Nouveaux rôles sur le blog : éditeur·rice·s, traducteur·rice·s, interviewé·e·s

Les métadonnées de nos articles de blog comportent désormais :

qui a édité l’article de blog
- par exemple, Steffi LaZerte a modifié un article récent.
qui a traduit l’article de blog
- par exemple, Yanina Bellini Saibene a traduit un article en espagnol et Maëlle Salmon l’a traduit en français.
qui était interviewé pour un article de blog
- par exemple, Athanasia Mo Mowinckel a été interviewée dans la série Étoiles de R-universe..

La “page auteur·rice” des contributeur·rice·s énumère leurs diverses contributions au contenu dans la langue actuelle (les articles en tant qu’auteur·rice sont listés en premier, suivis des autres rôles) :

Pour réaliser cette nouvelle fonctionnalité, nous avons

modifié les layouts (modèles) de Hugo pour les articles de blog et pages d’auteur·rice.
documenté les nouveaux champs de métadonnées correspondants dans notre guide pour le blog.

Conclusion

Nous sommes ravi·e·s de pouvoir reconnaître davantage de contributions à notre blog.

Cette différenciation des rôles nous permet également d’analyser plus en détail la façon dont les collaborations liées au blog se produisent parmi les membres de notre communauté. Grâce à ces informations, nous pouvons explorer différentes façons d’encourager la participation des personnes intéressées, y compris la meilleure façon de fournir le soutien nécessaire à une participation réussie.

Nous espérons également que nos résultats seront utiles à d’autres communautés pour identifier les différents types de contributions et les façons de les honorer.

Nous continuerons à travailler pour que davantage de ces contributions soient présentées dans notre fil d’actualité sur Rogue Scholar.

Une introduction en douceur à la science ouverte

rOpenSci — Tue, 23 Sep 2025 00:00:00 +0000

Read it in: English.

Sunny et Steffi montrent leurs autocollants R hex !

Cet été, j’ai eu le plaisir de participer à la Société des ornithologistes du Canada à Saskatoon au Canada. C’était génial de croiser Sunny Tseng, Championne rOpenSci et collègue ornithologiste! Ce n’est pas souvent que je rencontre les deux types de collègues (développeur·se·s R et ornithologistes) lors d’une même conférence, alors je chéris ces expériences.

Avant de rejoindre rOpenSci, j’ai commencé ma carrière professionnelle en tant qu’écologiste comportementale et ornithologiste, étudiant les effets du bruit urbain et de l’habitat sur la communication chez les mésanges. Alors que je me suis reconvertie dans le conseil et l’assistance en matière de R ainsi que le travail avec Yani ici à rOpenSci avec notre incroyable communauté, je travaille encore aujourd’hui principalement pour d’autres ornithologistes ou des organisations à but non lucratif de conservation des oiseaux.

Cela signifie que la Société des ornithologistes du Canada est toujours mon organisation d’origine et je suis toujours enthousiaste à l’idée d’assister à des réunions et de renouer avec mes collègues. Mais conférence ornithologique ou pas, j’essaie toujours d’apporter un peu de R, de Science Ouverte et de rOpenSci à la réunion.

Dans le passé, j’ai organisé des symposiums sur des sujets tels que “R pour les ornithologues : Points de vue des utilisateuRs et programmeuRs” ou “Comment les ornithologues peuvent-il·elle·s trouver des paquets R ?” et j’ai participé à l’organisation d’ateliers sur les paquets R pour l’ornithologie (comme bbsBayes2).

Cette année, j’ai eu envie d’aller un peu plus loin que R et j’ai décidé de parler de “Conseils pratiques pour la science ouverte en ornithologie”. Mon objectif était d’encourager les ornithologistes (ou d’autres scientifiques) à essayer la science ouverte. Pour se rendre compte qu’il n’est nécessaire ni d’avoir une formation en informatique, ni d’avoir beaucoup d’argent ! Et comme l’ornithologie compte de nombreux scientifiques qui travaillent déjà avec des données ouvertes, des méthodes ouvertes et la science ouverte, je voulais partager quelques idées sur la manière dont il·elle·s pourraient encourager un plus grand nombre de leurs collègues à se joindre à elleux.

Pour la communauté rOpenSci, il s’agit d’un véritable “retour aux sources”. Les conversations que nous avons portent plus souvent sur la façon dont on peut devenir meilleur·e en science ouverte ? Comment rendre cette étude complètement reproductible ? Comment améliorer la qualité du code ouvert¹?

Diapositive reconnaissant que la science ouverte peut être un défi
(Grey-crowned crane - Kuribo, CC BY-SA 2.0)

Mais je pense que nous oublions parfois qu’en plus du temps, des compétences et parfois du financement, la pratique de la science ouverte demande beaucoup de courage².

Pour celleux qui débutent (comme les étudiant·e·s) ou celleux qui n’ont pas de soutien en matière de science ouverte (comme les chercheur·se·s des petites institutions), la pratique de la science ouverte peut sembler écrasante et extrêmement intimidante. Il est effrayant de penser aux critiques si l’on ne “fait pas de la science ouverte correctement”, ou aux conséquences si l’on commet une erreur.

J’ai voulu mettre l’accent sur les petits pas, pour qu’il soit clair que c’est l’effort qui est important, et non la perfection !

En plus de quelques conseils pratiques, j’ai donc donné quatre conseils généraux :

Ne pas essayer de tout faire
- Soyez gentil·le avec vous-même
- Vous avez le droit de commencer petit et de grandir !
Faites une nouvelle chose
- Pour chaque projet, essayez d’élargir vos compétences, d’apprendre une nouvelle chose.
C’est normal d’être nerveux·se
- Les erreurs arrivent, mais n’oubliez pas qu’en pratiquant la science ouverte, vous êtes déjà génial·e !
Travailler avec d’autres
- Trouver sa communauté

Je pense que ce qui m’a le plus plu dans cette conférence, c’est le nombre d’étudiant·e·s qui sont venu·e·s me parler par la suite, enthousiastes (et nerveux·ses) à l’idée de commencer à partager leur code en ligne. Il·elle·s m’ont posé de nombreuses questions, qu’il s’agisse de questions pratiques sur l’utilisation de GitHub ou de questions générales sur la qualité de leur code pour qu’il soit partagé. Ma réponse à cette dernière question a été : “Si vous l’avez utilisé, partagez-le. (Mais annotez-le énormément !)”

Quels sont vos conseils préférés pour encourager la science ouverte ?

Remerciements

Remerciements à Alex Koiter pour les idées et le remue-méninges pour mon exposé, ainsi que pour son exposé génial (et beaucoup plus long), Open and Reproducible Soil Science.

Trisovic A, Lau MK, Pasquier T, et al. A large-scale study on research code quality and execution. Sci Data 9, 60 (2022). https://doi.org/10.1038/s41597-022-01143-6 ↩︎
Insécurité: Gomes DGE, Pottier P, Crystal-Ornelas R, et al. Why don’t we share data and code? Perceived barriers and benefits to public archiving practices. Proc Biol Sci 289(1987):20221113 (2022). https://doi.org/10.1098/rspb.2022.1113 ↩︎

Toutes les façons d'éditer ou d'analyser programmatiquement des documents R Markdown / Quarto

rOpenSci — Thu, 18 Sep 2025 00:00:00 +0000

Read it in: English.

Read it in: Español.

Si la vie te donne un tas de fichiers Markdown à analyser ou à éditer, est-ce que tu fais chauffer tes muscles regex avant de te lancer ? Et si tu utilisais plutôt des outils plus spécifiques ? Dans ce billet, nous allons donner un aperçu des moyens programmatiques d’analyser et d’éditer les fichiers Markdown : Markdown, R Markdown, Quarto, fichiers Hugo, et plus encore.

Qu’est-ce que Markdown ?

Markdown est un langage de balisage créé par John Gruber et Aaron Swartz. Voici un exemple :

# Mon premier titre

Contenu, avec des parties en **gras** ou *italique*.
J'ajoute un [lien](https://ropensci.org).

Différents fichiers Markdown peuvent conduire au même résultat, par exemple ceci est équivalent à notre premier exemple :

Mon premier titre
===============

Contenu, avec des parties en __gras__ ou _italique_. J'ajoute un [lien](https://ropensci.org).

De plus, il existe différents flavours (saveurs) ou spécifications (specs) de Markdown ¹ qui ajoute des syntaxe étendues comme les emojis écrits avec des deux-points.

Les utilisateur·rice·s de R interagissent généralement avec les différentes saveurs de Markdown par le biais de leurs outils habituels :

R Markdown qui utilise Pandoc sous le capot,
Quarto (qui utilise Pandoc sous le capot… tu vois une tendance ?),
GitHub qui utilise GitHub Flavored Markdown (GFM),
Markdown dans roxygen2 qui utilise Commonmark par l’intermédiaire de {commonmark},
Hugo, pour blogdown ou hugodown qui utilisent Commonmark et GFM,
Jekyll qui utilise GFM avec des spécificités à travers kramdown.

De nombreux outils utilisant Markdown acceptent également un frontmatter (en-tête): métadonnées en tête des fichiers Markdown, par exemple YAML, TOML ou JSON. Voici un exemple avec un en-tête YAML :

---
title: Mon truc cool
author: Moi-même
---

Contenu, *bon* contenu.

Le plus souvent, les utilisateur·rice·s de R écrivent du Markdown manuellement, ou à l’aide d’un éditeur tel que l’éditeur visuel Positron ou l’éditeur visuel RStudio IDE. Mais parfois, il faut créer ou modifier un grand nombre de fichiers Markdown en même temps, et modifier tous ces fichiers à la main est une énorme perte de temps. Cet article de blog te donnera des ressources en R que tu pourras utiliser pour créer, analyser et modifier des documents Markdown, afin que tu puisses devenir le·a magicien·ne Markdown que tu as toujours rêvé de devenir 🧙 !

Morceaux de code et programmation lettrée

En Markdown, tu peux ajouter des morceaux de code, qui seront correctement formatés et mis en évidence, en utilisant la syntaxe suivante :

```r
1 + 1
```

Les outils de programmation lettrée tels que knitr (pour R Markdown et Quarto) te permettront d’ajouter des morceaux de code qui seront exécutés pour rendre le document :

```{r}
#| label: my-chunk
#| echo: true
1 + 1
```

Cette dernière syntaxe, les chunks de code exécutables, n’est pas forcément bien gérée par les outils “normaux” comme Pandoc. C’est quelque chose qu’il faut garder à l’esprit si tu as affaire à des documents qui contiennent des morceaux de code exécutables.

Outils de création pour les documents standard

Imagine que tu doives créer un tas de fichiers R Markdown différents, par exemple pour que les élèves les utilisent comme exercices personnalisés. Dans ce cas, tu peux créer un document comme modèle, et créer ses différentes versions de sortie à l’aide d’un outil de création de modèles.

Les outils de création de modèles comprennent :

knitr::knit_expand() par Yihui Xie ;
le paquet whisker maintenu par Edwin de Jonge (utilisé par exemple dans pkgdown) ;
le paquet brew maintenu par Greg Hunt ;
Pandoc de John MacFarlane par le biais de son modèles.

L’exemple le plus simple du paquet whisker pourrait en outre te rappeler le… paquet glue.

Un flux de travail courant serait le suivant :

Tu crées un modèle dans un fichier, où les parties variables sont indiquées par des chaînes de caractères telles que {{name}}.
Tu lis ce modèle dans R en utilisant par exemple le paquet brio.
En faisant correspondre ton ensemble de variables, tu rends le modèle à l’aide de Whisker et tu enregistres chaque version dans un fichier à l’aide du paquet brio.

Exemple

Voici un exemple de fichier Markdown que nous pouvons utiliser comme modèle :

---
title: "Devoir maison 1"
author: "{{nom}}"
---

Créez une distribution normale avec une moyenne de {{moyenne}} et un écart-type de {{sd}} :

```{r solution-1}
# indice: utilisez la fonction rnorm
```

En utilisant le flux de travail ci-dessous, nous pouvons créer différents documents Markdown correspondant à différents élèves.

# génération des variables ----
etudiants <- c("Maëlle", "Christophe", "Zhian")
n <- length(etudiants)
clef <- data.frame(
  nom = etudiants,
  moyenne = rpois(n, 5),
  sd = sprintf("%.1f", runif(n)),
  fichier = sprintf("%s-hw.fr.md", etudiants)
)
# création des devoirs à partir du modèle ----
make_assignment <- function(clef, modele) {
  lapply(seq(n), function(i) {
    new <- whisker::whisker.render(modele, data = clef[i, ])
    brio::write_lines(new, clef$fichier[i])
  })
  return(invisible())
}
md <- brio::read_lines("hw-template.fr.md")
make_assignment(clef, modele = md)
print(clef)
#>          nom moyenne  sd             fichier
#> 1     Maëlle       7 0.1     Maëlle-hw.fr.md
#> 2 Christophe       8 0.7 Christophe-hw.fr.md
#> 3      Zhian       2 0.8      Zhian-hw.fr.md

Voici à quoi ressemblent les devoirs de Zhian :

---
title: "Devoir maison 1"
author: "Zhian"
---

Créez une distribution normale avec une moyenne de 2 et un écart-type de 0.8 :

```{r solution-1}
# indice: utilisez la fonction rnorm
```

Outils de manipulation des chaînes de caractères

Tu peux utiliser des outils de manipulation de chaînes pour analyser Markdown si tu es sûr·e des variantes de Markdown que ton code recevra en entrée, ou si tu es prêt·e à développer ta base de code pour prendre en compte de nombreux cas de figure… ce qui signifie en fin de compte que tu écris un véritable analyseur Markdown. Ce n’est pas pour les âmes sensibles… et ce n’est pas nécessaire si tu lis la section qui suit celle-ci 😌

Tu détectes les titres en utilisant par exemple grep("^#", markdown_lines) ² .

Parmi les exemples d’outils de manipulation de chaînes de caractères, on peut citer R base (sub(), grep() et ses amis), stringr (et stringi), xfun::gsub_file().

Bien que les outils de manipulation de chaînes de caractères soient d’une utilité limitée lors de l’analyse de Markdown, ils peuvent compléter les outils d’analyse proprement dits. Même si l’utilisation d’outils d’analyse Markdown spécifiques t’aidera à écrire moins d’expressions régulières toi-même… ils ne t’en libéreront pas complètement.

Outils de manipulation des représentations abstraites

Les outils de manipulation des représentations abstraites sont fantastiques et nombreux. Ils traduisent le document Markdown en une structure de données appelée abstrait Syntax Tree (AST) qui te permet de contrôler finement des éléments spécifiques du document (par exemple, des titres ou des liens individuels, quelle que soit la façon dont ils sont écrits). Grâce à une structure de données formelle, tu peux manipuler par programme le document Markdown en ajoutant, en supprimant ou en manipulant des éléments de Markdown d’une manière standardisée.

Certains de ces outils te permettent de lire, d’éditer et de manipuler des documents Markdown et de les réécrire.

Nous ne mentionnerons que les outils que tu peux utiliser directement à partir de R.

Exemple de cas d’utilisation

Disons que tu as créé une série de tutoriels qui renvoient à un site Web contenant une galerie d’extensions pour un paquet populaire de visualisation de données. Disons aussi qu’un jour, quelqu’un découvre que le lien vers le site Web soudainement… redirige vers un site potentiellement malveillant qui n’a certainement rien à voir avec la grammaire des graphiques et tu dois remplacer toutes les occurrences de ce lien par **redacted**. Étant donné que les liens en Markdown peuvent être écrits de plusieurs façons, les expressions régulières ne t’aideront pas, mais un analyseur Markdown à granularité fine le fera !

Un flux de travail pour cette situation serait le suivant :

lis l’AST Markdown avec ton analyseur préféré
retire tous les liens qui pointent vers le lien pourri
remplace-les par un texte en surbrillance qui dit “modifié”.
convertis l’AST et écris-le dans le fichier

{tinkr}

Le paquet tinkr créé par Maëlle Salmon et maintenu par Zhian Kamvar, analyse Markdown en XML en utilisant Commonmark, te permet d’extraire et de manipuler Markdown en utilisant XPath via le paquet xml2. Tinkr réécrit le XML en Markdown à l’aide de XSLT. Les métadonnées YAML sont disponibles sous forme de chaîne de caractères. Tinkr prend en charge les morceaux de code exécutables.

Le paquet tinkr est utilisé dans les paquets babeldown et aeolus.

{md4r}

Le paquet md4r est un paquet expérimental récent maintenu par Colin Rundel. Il s’agit d’une enveloppe R autour de la bibliothèque MD4C (Markdown for C) qui représente l’AST sous forme de liste imbriquée avec des attributs dans R. La version de développement du paquet comporte des utilitaires permettant de construire des documents Markdown de manière programmatique.

Pandoc

Avec Pandoc que nous avons présenté dans un note technique tu peux transformer un fichier Markdown en un arbre syntaxique abstrait Pandoc (soit dans son format natif, soit en JSON).

Comment utiliser Pandoc pour éditer et réécrire un fichier Markdown ?

En utilisant des filtres Lua : Pandoc convertit en AST dans son format natif, les filtres Lua permettent de le traiter pour le modifier, puis Pandoc peut écrire en markdown.
Utilisation de filtres JSON : Pandoc convertit en AST en produisant une représentation JSON, puis n’importe quel outil peut modifier ce fichier JSON et fournir une version modifiée à Pandoc pour qu’il la convertisse à nouveau en markdown.

Note que Pandoc ne prend pas en charge les morceaux de code exécutables, car il ne sera pas en mesure d’analyser les morceaux de code exécutables en tant que Codeblock.

{parseqmd}

Nic Crane a créé un paquet expérimental appelé parseqmd qui utilise cette stratégie, en analysant la sortie à l’aide de l’outil jsonlite . Tu peux aussi transformer le Markdown en HTML, par exemple, puis revenir à Markdown. L’avantage du HTML est que tu peux utiliser un paquet tel que xml2 ou rvest pour extraire et manipuler les éléments.

{parsermd}

Le paquet parsermd est également maintenu par Colin Rundel et est une “implémentation d’une grammaire formelle et d’un analyseur pour les documents R Markdown en utilisant la bibliothèque Boost Spirit X3. Il comprend également une collection de fonctions de haut niveau pour travailler avec l’arbre syntaxique abstrait résultant.”

Ce paquet possède des fonctionnalités pour un flux de travail “tidy” te permettant de sélectionner différentes sections du document. Une caractéristique utile est qu’il possède la fonction rmd_check_template() qui te permet de comparer les documents Markdown soumis par des étudiants par exemple, à un modèle standard. Tu peux regarder sa présentation à la conférence RStudio::conf(2021).

Le paquet parsermd te permet même de modifier les documents.

{lightparser}

Le paquet lightparser de Sébastien Rochette “divise tes fichiers rmarkdown ou quarto par sections dans un tibble : titres, texte, chunks ; reconstruit le fichier à partir du tibble”. Il peut être utilisé pour traduire des documents par exemple.

L’impossibilité d’un aller-retour parfait

Lorsque l’on analyse et modifie du Markdown, puis que l’on réécrit en Markdown, certaines modifications indésirables peuvent apparaître. Par exemple, avec tinkr les éléments de la liste commencent tous par un - même si dans le document original ils commençaient par un *. Avec md4r, les listes qui sont indentées avec un espace supplémentaire seront réajustées.

En fonction de ton cas d’utilisation, tu peux trouver des moyens d’atténuer ces pertes, par exemple en ne réécrivant que les lignes sur lesquelles tu as fait des modifications intentionnelles.

Comment choisir un analyseur ?

Tu peux choisir un analyseur en fonction de ce qu’il te permet de manipuler avec le Markdown : si tu préfères XML³ et HTML aux listes imbriquées, par exemple, tu préféreras utiliser tinkr ou Pandoc. Si les fonctions de haut niveau de md4r ou parsermd conviennent à ton cas d’utilisation, tu peux préférer l’un d’entre eux.

Il est important de noter que si tes documents contiennent des morceaux de code exécutable, tu dois utiliser un outil qui les prend en charge, comme parsermd, lightparser, tinkr.

Un autre critère important est de choisir un analyseur syntaxique qui se rapproche le plus possible du cas d’utilisation de tes fichiers Markdown. Si tu ne comptes travailler avec des fichiers Markdown que pour GitHub, commonmark/tinkr est un excellent choix puisque GitHub lui-même utilise commonmark. Maintenant, ton travail peut englober différentes sortes de fichiers Markdown qui seront utilisés par différents outils. Par exemple, l’outil babeldown traite n’importe quel fichier Markdown⁴: Markdown, R Markdown, Quarto, Hugo. Dans ce cas, ou si aucun analyseur R ne fait exactement ce que fait l’utilisateur·rice final·e de ton Markdown, tu dois faire attention aux bizarreries de cet utilisateur·rice final·e. Tu devras peut-être ajouter des attributs bruts de Pandoc autour d’un shortcode Hugo, par exemple. De plus, si tu as besoin d’analyser certains éléments, comme encore une fois les shortcodes Hugo, tu peux avoir besoin d’écrire le code d’analyse toi-même, c’est-à-dire des expressions régulières.

Qu’en est-il des morceaux de code ?

L’analyse et l’édition programmatiques du code R n’entrent pas dans le cadre de ce billet, mais sont suffisamment proches pour que tu y ajoutes quelques conseils.

Expressions régulières

Comme pour Markdown, tu peux avoir besoin d’utiliser des expressions régulières, mais c’est une approche risquée, car par exemple plot (x) et plot(x) sont tous deux des appels de fonction valides dans R.

{xmlparsedata}

Tu peux analyser le code en XML à l’aide de l’analyseur de base R et de l’analyseur de code XML. xmlparsedata puis tu manipules le XML avec XPath. Pour réécrire le code, tu peux utiliser les attributs de chaque nœud qui indiquent les lignes et les colonnes d’origine.

Ainsi, un flux de travail possible, tel qu’il est illustré dans l’article de Maëlle est le suivant :

Transforme le code en XML, utiliser xmlparsedata pour savoir ce qu’il faut changer et où. Ces étapes te permettront d’obtenir une liste des positions des éléments, par exemple.
Utilise brio pour lire les lignes, modifie-en quelques-unes avec les outils de base de R, puis utilise à nouveau brio pour réécrire les lignes.

{treesitter}

tree-sitter par Davis Vaughan “fournit des liens R à tree-sitter, un système d’analyse incrémentielle”.

Qu’en est-il des métadonnées ?

Nous avons consacré tout ce billet à la question du corps des documents Markdown. Qu’en est-il des métadonnées contenues dans leur frontmatter, comme par exemple :

---
title: "Cool doc"
author: "Jane Doe"
---

Pour extraire ou modifier les métadonnées YAML/TOML/JSON, tu dois d’abord décapiter les documents Markdown. Par exemple, rmarkdown possède une fonction appelée rmarkdown::yaml_front_matter() pour extraire les métadonnées YAML d’un document R Markdown ; le paquet R quarto possède une fonction appelée quarto::quarto_inspect() qui, entre autres choses, produit les métadonnées.

Tu peux lire les lignes du document Markdown en utilisant readLines() ou brio::read_lines() avant de recourir à des expressions régulières pour identifier le début et la fin de la page de garde en fonction de son format.

Ensuite, pour gérer YAML, tu utiliseras {yaml} et pour gérer TOML, tu pourrais utiliser {tomledit} ou {RcppTOML} Pour gérer JSON, tu peux utiliser {jsonlite}.

Enfin, si tu as besoin de réécrire le document Markdown, tu écriras ses lignes en utilisant writeLines() ou brio::write_lines().

Exemples d’analyse et d’édition Markdown

Le paquet pegboard créé par Zhian Kamvar et maintenu par The Carpentries, analyse et valide les leçons de Carpentries pour les éléments structurels de Markdown, y compris les liens valides, le texte alt, et les fenced-divs connus grâce à tinkr. Ce paquet a permis de convertir toute l’infrastructure des leçons de The Carpentries de la syntaxe Markdown de Jekyll à la syntaxe Markdown de Pandoc. ⁵ .

Le paquet babeldown maintenu par Maëlle Salmon transforme Markdown en XML, l’envoie à l’API DeepL pour traduction, et réécrit les résultats en Markdown, en utilisant également tinkr.

Conclusion

Dans ce billet, nous avons expliqué comment analyser et éditer au mieux les fichiers Markdown. Pour créer des documents à partir d’un modèle (comme du publipostage), nous avons recommandé des outils de modélisation tels que knitr::knit_expand(), le paquet whisker, le paquet brew, Pandoc. Pour éditer de petites parties d’un document, nous avons fait appel à des outils de manipulation de chaînes de caractères, c’est-à-dire des expressions régulières, avec R base (sub(), grep() et ses amis), stringr (et stringi), xfun::gsub_file(). Pour une manipulation plus lourde, et plus sûre, nous avons listé des outils basés sur des outils qui manipulent la représentation abstraite des documents : tinkr, md4r, Pandoc, parseqmd, parsermd, lightparser. Nous avons également mentionné des outils permettant de travailler avec le code R à l’intérieur des cellules de code, et pour travailler avec le frontmatter YAML/TOML/JSON.

Qu’est-ce que tu utilises pour gérer les fichiers Markdown ?

En date du 2024-06-20, il y a 76 programmes qui analysent Markdown dont certains ont une saveur particulière. ↩︎
Mais cela détecterait également les commentaires de code ! Ne fais pas ça ! ↩︎
Maëlle et Zhian sonténormes fans de XML et de XPath (voir : https://masalmon.eu/2022/04/08/xml-xpath/ et https://zkamvar.netlify.app/blog/gh-task-lists/). ↩︎
Ou du moins c’est censé être le cas :sweat_smile : Heureusement, les utilisateur·rice·s signalent des cas limites qui ne sont pas encore couverts. ↩︎
Pour des exemples, voir The Carpentries Workbench Transition Guide. ↩︎

Publication multilingue : Questions fréquemment posées

rOpenSci — Mon, 23 Jun 2025 00:00:00 +0000

Read it in: Español.

Read it in: English.

Comme nous l’avons nous l’avons déjà dit, nous pensons que la publication de ressources multilingues peut abaisser la barrière d’accès au savoir, aider à démocratiser l’accès à des ressources de qualité et augmenter les possibilités de contribuer à des logiciels et à des projets de science ouverte. Nos efforts continus de publication multilingue sont cruciaux pour la mission de rOpenSci. En présentant ce projet à des conférences et ailleurs, nous entamons une conversation importante avec des personnes moins familières avec ce type de projet ou qui ne connaissent pas nos méthodes de travail. Dans ce billet, nous résumons les questions fréquemment posées, et nos meilleures réponses à ces questions (encore mieux formulées que dans le feu de l’action lors d’une séances de questions après une présentation 😁).

Les traductions rendront-elles les gens “paresseux” en ce sens qu’il·elle·s n’apprendront pas l’anglais ?

Tout d’abord, il est important de préciser que pas n’apprend pas l’anglais ne signifie pas que les gens sont paresseux. De nombreuses personnes qui ne parlent pas anglais parlent déjà plusieurs langues, et même si elles n’en parlent qu’une, travailler sur son projet avec les outils dont on dispose est déjà un travail suffisant.

Deuxièmement, notre objectif n’est pas que les gens deviennent anglophones. Les gens peuvent choisir (ou non) d’apprendre l’anglais à tout moment, mais le fait d’avoir d’abord appris à, disons, développer un logiciel en utilisant le français ne va pas les en empêcher. Notre objectif est que les gens puissent utiliser des logiciels libres et y contribuer, et cela ne devrait pas dépendre du fait qu’il·elle·s parlent anglais. Dans le domaine des sciences, il est déjà assez difficile de ne pas être de langue maternelle anglaise et il existe un grand “potentiel inexploité de locuteurs non natifs de l’anglais” ¹. Libérons ce potentiel !

Relatif : Est-ce si difficile de lire en anglais ?

Oui, c’est l’un des “multiples coûts liés au fait d’être un anglophone non natif dans le domaine des sciences” ¹ . De plus, plusieurs études ont démontré les difficultés d’apprendre à coder dans des langages de programmation basés sur l’anglais sans être anglophone, et les avantages d’avoir la possibilité d’apprendre dans sa langue maternelle.

Gou² a constaté que les personnes dont l’anglais n’est pas la langue maternelle se heurtaient à des obstacles dans la lecture de matériel pédagogique, la communication technique, la lecture et l’écriture de code, et l’apprentissage simultané de l’anglais et de la programmation. Ces difficultés trouvent leur origine dans la nécessité de développer la compréhension de l’anglais en même temps que l’on attend d’elles·eux qu’il·elle·s se familiarisent avec le sujet spécifique : dans notre cas, comment développer des logiciels libre et de haute qualité pour la recherche. Si vous avez déjà essayé d’apprendre les statistiques et R en même temps, vous avez peut-être une idée de la difficulté de la tâche. Ce type d’apprentissage double augmente la charge cognitive, ce qui peut entraver l’apprentissage³.

Une autre étude ⁴ suggère que si l’apprentissage de la programmation en anglais n’est pas nécessairement difficile pour tous les non-anglophones, l’inclusion de la langue maternelle des apprenant·e·s peut rendre l’expérience d’apprentissage plus claire, plus encourageante et plus agréable.

Pour en savoir plus sur le sujet, vous pouvez suivre le travail de Felienne Hermans, spécialisée dans la conception de langages de programmation, qui a développé un langage de programmation multilingue pour l’enseignement.

Relatif : Les gens devraient apprendre l’anglais

Certaines personnes assènent que l’on doit apprendre l’anglais si l’on veut travailler dans le domaine de la programmation et des sciences parce que l’anglais est la lingua franca de ces disciplines.

Malheureusement, même si c’était souhaitable, ce n’est tout simplement pas possible pour beaucoup de personnes, en particulier pour les programmeur·rice·s occasionnel·le·s ou les utilisateur·rice·s finaux·les. Il·elle·s n’ont pas forcément le temps, l’énergie ou l’argent pour apprendre la programmation et l’anglais en même temps ⁵.

Avec quelques chiffres : Le Cadre européen commun de référence pour les langues a établi un tableau des heures d’apprentissage guidé généralement nécessaires pour atteindre chaque niveau de compétence linguistique. Il s’agit des heures passées à étudier avec un·e professeur·e ou dans le cadre d’un apprentissage structuré.

Par exemple, en commençant en tant que débutant·e (A1), pour devenir intermédiaire (B1), il faudra environ 400 heures d’apprentissage guidé. En pouvant consacrer 5 heures par semaine il faudra 1,5 an et un budget minimum de 6 000 DOLLARS AMÉRICAINS pour apprendre l’anglais. À titre de référence, cela équivaudrait à deux ans de salaire pour une personne ayant un salaire minimum en Argentine. Ce montant ne prend pas non plus en compte le coût pour trouver le temps d’étudier (services de garde d’enfants, réduction du nombre d’heures de travail, etc.)

En traduisant les documents et les ressources, nous réduisons la charge qui pèse sur les non-anglophones. Plus il y a de personnes impliquées dans les logiciels libres et la science, plus nous bénéficions tous d’un plus grand réservoir d’expériences et d’expertise. Enfin, nous voulons que tout le monde ait les mêmes chances d’apprendre !

Pourquoi ne pas juste utiliser des traductions automatiques ?

Pour nos flux de traduction les traductions automatiques constituent la première étape, suivie des révisions humaines. Bien qu’il soit techniquement possible de publier directement des traductions automatiques ou d’utiliser des outils de traduction à la volée, il y a des inconvénients. Tout d’abord, il est bien documenté que la traduction automatique ne fonctionne pas bien pour les langues les moins courantes⁵. Même pour les langues courantes, les traductions automatiques comportent toujours des erreurs, et font des erreurs liées au contexte, à la grammaire et à la syntaxe, ainsi qu’aux marques de genre. La traduction automatique ne peut pas non plus localiser certains contenus, comme les expressions idiomatiques ou les symboles monétaires et numériques.

Si nous nous fions uniquement à la traduction automatique, le contenu dans des langues traduites sera de moins bonne qualité, ce qui reviendrait à accepter que les utilisateur·rice·s des langues semi-supportées ne méritent pas la même qualité que les autres. C’est pourquoi, à rOpenSci, des traducteur·rice·s humain·e·s sont impliqué·e·s dans le processus pour s’assurer que tout notre contenu est de bonne qualité, quelle que soit la langue.

Pourquoi ne pas utiliser `<insérer-le-nom-d'une-plateforme-de-traduction>` au lieu de Git et GitHub ?

Il existe de nombreuses plateformes différentes pour la traduction, ce qui est fantastique ! Cependant, nous sommes une communauté technique et nous traduisons et localisons du contenu technique. Nous utilisons déjà Git et GitHub dans nos autres flux de développement et de nombreux membres de notre communauté connaissent ces outils ou prévoient de les apprendre. Pour les membres qui ne connaissent pas Git et GitHub, nous avons des ressources et les aidons volontiers à apprendre, et il·elle·s disposent alors de nouveaux outils qu’il·elle·s peuvent appliquer à d’autres projets techniques. Pour en savoir plus sur nos outils et nos processus, consultez notre rubrique guide de traduction.

La traduction et la maintenance des traductions ne représentent-elles pas un travail considérable ?

Oui, c’est vrai ! Mais nous pensons que cela en vaut la peine. De plus, le travail de traduction apporte de nouveaux·elles contributeur·rice·s à la communauté, ce qui a) aide à partager la charge de travail, b) sert de tremplin à d’autres formes de contributions, et c) diversifie notre communauté.

Conclusion

Dans ce billet, nous avons répondu aux questions courantes que nous recevons sur notre projet de publication multilingue. Nous sommes convaincus que fournir des ressources multilingues de qualité fait partie du travail pour plus de diversité, l’équité, l’inclusion et l’accessibilité dans le logiciel libre et la science ouverte. Votre participation est la bienvenue… tout comme vos questions !

Amano T, Ramírez-Castañeda V, Berdejo-Espinola V, Borokini I, Chowdhury S, Golivets M, et al. (2023) The manifold costs of being a non-native English speaker in science. PLoS Biol 21(7) : e3002184.https://doi.org/10.1371/journal.pbio.3002184 ↩︎ ↩︎
Philip J. Guo. 2018. Les personnes dont l’anglais n’est pas la langue maternelle apprennent la programmation informatique : Barrières, désirs et possibilités de conception. Dans les actes de la conférence 2018 de la CHI sur les facteurs humains dans les systèmes informatiques (CHI ‘18). Association for Computing Machinery, New York, NY, États-Unis, document 396, 1-14.https://doi.org/10.1145/3173574.3173970 ↩︎
Goldin, A. (2022). Neurociencia en la escuela : Guía amigable (sin bla bla) para entender cómo funciona el cerebro durante el aprendizaje. Siglo XXI Editores. ↩︎
Ethel Tshukudu, Emma Dodoo, Felienne Hermans, et Monkgogi Mudongo. 2024. La programmation bilingue : Une étude sur les attitudes et les expériences des étudiants dans le contexte africain. Dans les actes de la 24e conférence internationale de Koli Calling sur la recherche en éducation informatique (Koli Calling ‘24). Association for Computing Machinery, New York, NY, États-Unis, article 42, 1-11.https://doi.org/10.1145/3699538.3699561 ↩︎
Alaaeddin Swidan et Felienne Hermans. 2023. Un cadre pour la localisation des langages de programmation. Dans les actes du 2023 ACM SIGPLAN International Symposium on SPLASH-E (SPLASH-E 2023). Association for Computing Machinery, New York, NY, États-Unis, 13-25.https://doi.org/10.1145/3622780.3623645 ↩︎ ↩︎

rOpenSci - open tools for open science

En route pour le lancement ! Paquets expédiés au R-Multiverse

Paquets soumis

riem, pour obtenir des données météorologiques des stations ASOS (aéroports) via l’Iowa Environment Mesonet.

geotargets, qui étend targets pour travailler avec des formats de données géospatiales

weathercan, pour trouver et télécharger des données météorologiques historiques d’Environnement et Changement Climatique Canada (ECCC)

Quelle est la suite pour ces paquets ?

Quelle est la suite pour le multivers R ?

Reconnaissance au-delà des auteur·rice·s de billets de blog

Nouveaux rôles sur le blog : éditeur·rice·s, traducteur·rice·s, interviewé·e·s

Conclusion

Une introduction en douceur à la science ouverte

Remerciements

Toutes les façons d'éditer ou d'analyser programmatiquement des documents R Markdown / Quarto

Qu’est-ce que Markdown ?

Morceaux de code et programmation lettrée

Outils de création pour les documents standard

Exemple

Outils de manipulation des chaînes de caractères

Outils de manipulation des représentations abstraites

Exemple de cas d’utilisation

{tinkr}

{md4r}

Pandoc

{parseqmd}

{parsermd}

{lightparser}

L’impossibilité d’un aller-retour parfait

Comment choisir un analyseur ?

Qu’en est-il des morceaux de code ?

Expressions régulières

{xmlparsedata}

{treesitter}

Qu’en est-il des métadonnées ?

Exemples d’analyse et d’édition Markdown

Conclusion

Publication multilingue : Questions fréquemment posées

Les traductions rendront-elles les gens “paresseux” en ce sens qu’il·elle·s n’apprendront pas l’anglais ?

Relatif : Est-ce si difficile de lire en anglais ?

Relatif : Les gens devraient apprendre l’anglais

Pourquoi ne pas juste utiliser des traductions automatiques ?

Pourquoi ne pas utiliser <insérer-le-nom-d'une-plateforme-de-traduction> au lieu de Git et GitHub ?

La traduction et la maintenance des traductions ne représentent-elles pas un travail considérable ?

Conclusion

Pourquoi ne pas utiliser `<insérer-le-nom-d'une-plateforme-de-traduction>` au lieu de Git et GitHub ?