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écemvre, 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 posée à 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 quête 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 ouun 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 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/. 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
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). • 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. • 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. • 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?
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.
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.