Ceci est une ancienne révision du document !
To begin this month’s article, I have an announcement to make. After 130 issues of FCM (my first article appeared in #21), I have finally reached the point in my life where I have trouble finding the time I need to dedicate to FCM on a regular basis. As such, my next article (December, issue 152) will be my last. I’d like to take this opportunity to thank the readers who reached out to me over the course of the last two articles with comments/responses. It’s always nice to be in contact with a reader. This month’s article will be a little different, as I have a question to pose to the community, an addition to last month’s article, and a small write-up of how I implemented translations into a small Gatsby site.
Pour commencer l'article de ce mois, j'ai une annonce à faire. Après 130 numéros du FCM (mon premier article est sorti dans le n° 21), j'ai enfin atteint un point de ma vie où il m'est difficile de trouver le temps nécessaire pour me consacrer au FCM de manière régulière. De sorte que mon prochain article (en décembre, le 152e) sera le dernier. J'aimerai en profiter pour remercier les lecteurs qui m'ont adressé des questions/réponses au cours des deux derniers articles. C'est toujours agréable d'être en contact avec les lecteurs.
L'article de ce mois sera un peu différent, car j'ai une question à poser à toute la communauté, un ajout à l'article du mois dernier et une courte note sur comment j'ai implémenté des traductions dans un petit site Gatsby.
The question to any fellow programmers I’ve decided to firm up my grasp of test-driven development so that I can more easily apply it to the projects I work on. The majority of my experience is with unit testing, and I know there is much, much more out there. As such, I ask that any readers who can recommend a book, course, video series, or podcast about test-driven development (it can be general/language-agnostic, python-focused, and/or web focus (ie. jest/React)). If I get enough responses, I’ll put together the list in next month’s article so anyone who’s interested can look it up for themselves. Anyone who has a recommendation can reach me at lswest34+fcm@gmail.com.
La question à tous les amis programmeurs
J'ai décidé de renforcer ma recherche sur le développement piloté par les tests, de façon que je puisse l'appliquer plus aisément aux projets sur lesquels je travaille. La majorité de mon expérience est sur les tests unitaires et je sais qu'il y a beaucoup, beaucoup plus que ça.
Ainsi, je demande aux lecteurs s'ils peuvent me recommander un livre, un cours, une série de vidéos ou un podcast sur le développement piloté par les tests (ce peut être général/sans lien avec un langage, centré sur Python et/ou centré sur le Web (par exemple, jest/React). Si je reçois assez de réponses, j'en ferai la liste dans l'article du mois prochain de façon à ce que tous ceux qui sont intéressés puissent y trouver ce qu'ils cherchent. Tous ceux qui ont des recommandations peuvent me joindre par lswest34+fcm@gmail.com.
Rust Tying this in with last month’s article on Rust - I completely neglected to mention Redox. Redox OS is a very interesting open source project to build a unix-like kernel in Rust. It’s not necessarily a fully-fledged replacement for Linux at the moment (and there’s no guarantee it will succeed), but the concept is extremely interesting to me. It’s also an ideal opportunity to see some real Rust code. Or if you ever wanted to witness an OS being built. The website is: https://www.redox-os.org/.
Rust
Ceci est en lien avec mon article du mois dernier sur Rust - j'ai complètement oublié de mentionner Redox. Redox OS est un projet Open Source vraiment très intéressant pour construire un noyau de type Unix dans Rust. Ce n'est pas nécessairement un remplaçant intégral de Linux pour le moment (et ce n'est pas garanti qu'il y arrive), mais le concept me paraît très intéressant. C'est aussi l'opportunité idéale pour voir un peu de code Rust, ou si vous n'avez jamais été témoin d'un OS en cours de construction. Le site Web est : https://www.redox-os.org/
Translations in Gatsby I won’t go into code here, but I want to describe my methodology, in case anyone wants some guidelines. Basic Setup •All mdx files are in a folder /src/content/{english,german} and are configured as separate filesystem-loaders. The nodes then have the sourceInstanceName added to them, for filtering purposes. • The basic approach was taken from here: https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n
Traductions en Gatsby
Je ne vais pas rentrer dans le code ici, mais je veux juste décrire ma méthodologie, au cas ou l'un de vous voudrait quelques explications.
Paramétrage de base
••Tous les fichiers mdx sont dans un dossier /src/content/{english,german} (anglais, allemand) et sont configurés comme des chargeurs de systèmes de fichiers séparés. Ensuite, il est ajouté sourceInstanceName aux nœuds pour des questions de filtrage. ••L'approche de base vient d'ici : https://github.com/gatsbyjs/gatsby/tree/master/examples/using-i18n
Non-standard setup Besides the two items listed above, there were a few things I did that I didn’t see listed anywhere: • I didn’t use an i18n translation system. 95% of the actual text on the site was coming from the mdx files and were, therefore, being translated automatically. • For the other 5%, I went for a simple JSX if/else ({locale === “en” ? “English” : “Deutsch”}). If more text was baked into the design, I probably would have integrated something like react-i18next or react-intl everywhere (there is an example in the repo listed above, but, based on the code I had at the time, it seemed like more work to implement that).
Paramétrage non-standard
À côté des deux points ci-dessus, il y avait quelques autres choses que j'ai faites qui n'apparaissent dans aucune liste : ••Je n'ai pas utilisé le système de traduction i18n. 95 % du texte réel du site venait de fichiers mdx et, par conséquent, ils étaient traduit automatiquement. ••Pour les 5 % restants, je suis passé par un simple if/else en JSX ({locale === “en” ? “English” : “Deutsch”}). Si la conception avait utilisé plus de texte, j'aurais, probablement, intégré quelque chose comme react-i18next ou react-intl partout (un exemple est disponible dans le dépôt cité plus haut, mais, comme il est basé sur le code que j'avais à ce moment-là, il m'a semblé qu'il reste encore du travail pour l'implémenter).
• A few components didn’t use graphql queries, so I simply passed the locale through, instead of setting up a context for it. If there had been more levels to the components, I could see myself using context for this. • The menu, unfortunately, required me to load both translations (into aliased queries) so that I could generate the menu. If, at some point, Gatsby allows you to pass a variable into a StaticQuery, it might be possible to do it differently. As it is, this isn’t a huge issue. Just configure a reusable variable based on the current locale, and then map your way through it.
••Quelques composants n'utilisaient pas les requêtes graphql ; aussi, j'ai simplement transmis la locale, plutôt que de paramétrer un contexte dédié. S'il y avait eu plus de niveaux pour ces composants, j'aurais probablement utilisé un contexte pour cela. ••Le menu, malheureusement, m'obligeait à charger les deux traductions (dans des requêtes avec alias) de sorte que je puisse générer le menu. Si, à un endroit particulier, Gatsby vous permettait de passer une variable dans un StaticQuery, il pourrait être possible de le faire différemment. Comme c'est maintenant, ce n'est pas un gros problème. Configurez simplement une variable réutilisable basée sur la locale en cours et et tirez-en votre solution avec elle.
• gatsby-node.js - I followed the example in the above repo, and then added a few things on top. First of all, I filtered my content via the sourceInstanceName, instead of the locales (as I had originally done it that way when starting off). I also have the files named for the pages, instead of having a folder named X with an index.mdx file in it, as was the case in the repo. Instead, in onCreateNode, I check the last 3 characters of the file name (as German was .de.mdx, and the .mdx extension was cut off earlier) to see if they matched “.de”. If it didn’t, I knew it was my “standard” language (English). I also tweaked the system that created the slugs, as the paths weren’t just the folder names. I also utilized a frontmatter field called “path”, as I wanted to be able to define custom slugs.
••gatsby-node.js - J'ai suivi l'exemple du dépôt pré-cité et, ensuite, j'ai ajouté quelques éléments par dessus. D'abord, j'ai filtré mon contenu via sourceInstanceName, plutôt que par les locales (comme je l'avais fait une première fois au tout début). J'ai aussi donné le nom des pages aux fichiers, au lieu d'avoir un dossier nommé X avec un fichier index.mdx dedans, comme ça l'était dans le dépôt. À la place, dans onCreateNode, je vérifie les 3 derniers caractères du nom du fichier (car en allemand, c'était .de.mdx et l'extension .mdx avait été supprimée avant) pour voir s'ils correspondaient à « .de ». Si non, je savais que c'était dans ma langue « normale » (l'anglais). J'ai aussi ajusté le système qui appelle les « slugs » (courte URL des blogs), car les chemins n'étaient pas faits des seuls noms de dossiers. J'ai aussi utilisé un champ préalable appelé « path » (chemin), car je voulais pouvoir définir des slugs spécifiques.
• Switching between languages - I gave each .mdx file a “translation” field, that was simply the base slug name I’d used for the other language. Using this and a JS helper function, I could accurately generate a link to swap between, regardless of actual names. Sure, I’d have to adjust the field if a slug were to change, but this should be a very rare occurrence. So, that’s the basic gist of it. I split the language up by defining multiple filesystems, and adjusted the code from the repository I listed earlier (using-i18n) to suit the existing code I had, and to reduce the amount of coding required to get a working website. After all, you can always tweak and improve it later, right?
••Commutation entre langues - j'ai donné à chaque fichier .mdx un champ de « traduction », qui contenait simplement la base du nom du slug que j'avais utilisé dans l'autre langue. En l'utilisant avec une fonction d'aide en JS, je pouvais générer précisément un lien pour la commutation, sans tenir compte des noms réels. Bien sûr, je devais ajuster le champ si un slug changeait, mais ça n'arrivait que très rarement.
Voici donc son gist de base. J'ai séparé les langues en définissant plusieurs systèmes de fichiers, et j'ai ajusté le code dans les dépôts cités plus haut (« using-i18n », utilisant i18n) pour correspondre au code que j'avais réellement, et pour réduire la masse de code nécessaire pour faire marcher un site Web. Après tout, vous pouvez toujours l'ajuster et l'améliorer ensuite, n'est-ce-pas ?
Speaking of tweaking and improving, here’s a slightly off-topic tip. I’ve recently had to rework a React app that relied way too heavily on Redux. I realize that Redux is useful and was popular for a time. That being said, if you choose to use Redux, please use it only for global state. Realistically, you shouldn’t need to ever rely on a state manager, as state is baked right into React. It’s especially easy with hooks (useState and useContext)! However, if you want to use Redux, just make sure that it’s actually global state in the sense that it’s used in 90% of files. If not, it’s most likely either local state, or something that should become a context somewhere along the DOM and passed in only to the children of the component. It will make a noticeable speed difference if your state changes trigger the minimum required re-renders.
À propos d'ajustement et d'amélioration, voici un conseil un peu hors sujet. J'ai dû récemment retravailler une appli en React qui s'appuyait trop largement sur Redux. Je sais que Redux est utile et a eu un moment de popularité. Ceci dit, si vous choisissez d'utiliser Redux, ne l'utilisez que pour un « state global » (appelé aussi « store »). En réalité, vous ne devriez jamais faire confiance à un gestionnaire de state, car les états (state) sont directement fondus dans React. C'est particulièrement facile avec les crochets (hooks UseState et useContext) ! Cependant, si vous voulez utiliser Redux, assurez-vous simplement que c'est vraiment un état global dans ce sens qu'il est utilisé dans 90 % des fichiers. Sinon, il vaut mieux utiliser, soit l'état local, soit quelque chose qui deviendrait un contexte quelque part dans le DOM et transmis seulement aux enfants du composant. Cela fera un différence notable de vitesse si votre changement d'état déclenche les réaffichages requis minimum.
I hope this article has been interesting to some. I’m looking forward to hearing from my readers in response to my question. If you’re working on a Gatsby site with multiple languages - what was your approach? As always, all comments, questions, and suggestions can be sent to me at lswest34+fcm@gmail.com.
J'espère que cet article en a intéressé quelques-uns. Je suis impatient de vous lire en réponse à ma question. si vous travaillez sur un site Gatsby avec plusieurs langues, quelle a été votre approche ? Comme d'habitude, les questions et suggestions peuvent m'être envoyées à lswest34+fcm@gmail.com.