I18n Pizzazz in Rust

I thought I'd post some programming stuff since I haven't in a while.

A while ago I explored a bit Rust's i18n options. I found a couple of libraries, but the more serious of them was this one called rust-i18n, or something like that. It's still probably the most popular one, if you go looking for it.

I used it for a bit in this project of mine, with the intention of using it later on too in another project, and then another... But then I started thinking, "why not just write this myself?"

It's a common question I ask myself. "Why use someone else's stuff when I could do this myself, so it's sufficient for my needs?" Usually, it's a little more effort but the end result turns out way simpler.

And what's especially pleasing is that I'll learn more. I'll learn exactly what dependencies are pulled and why, and I'll learn exactly the options I have about implementation details.

For instance, I've learned what the most popular Rust packages are and, perhaps, why. Turns out they're mostly about zero-copying and compile-time stuff. Yes, so optimization shenanigans.

In most cases, I don't think it's particularly relevant, though. There's always a way to implement things yourself. For example, even if you don't know how to write functional macros in Rust, you could still do some computations beforehand, simply by writing into a file, if you need to. Because you have to do it at some point, regardless.

But I digress. One thing that bothered me about rust-i18n or whatever, was that it didn't panic whenever it didn't find a translation in the file. So, whenever a program got complex enough, that would've made it more difficult to find which translations were missing.

And there were other things too. For example, I didn't really care whether it supported JSON or YAML, or even XML, for the translation files. I didn't really care whether it supported multiple files or a single file, either. All of that could be solved with a simple Bash script, if need be, and my use cases are probably never going to be so byrocratic, after all.

Download my crummy i18n library here, if you want. Expect updates in case I find bugs; I use it myself. I've considered for a while adding in functionality to deal with area codes, such as in en-US or en-GB and so on, but turns out I don't really care about those at all either, among the other things. There are other i18n libs that deal with that stuff in a sophisticated way. And, in many cases, you can get away with either British or American English, for example. Should be trivial to add that in though, we'll see.

I've also played around with the idea of using it for firmware or some kind of low-memory device. The compilation still needs std, but I've kind of looked out for the possibility that it should emit only stack-allocated structures and code. Might work already in no_std, I'm not sure. I'm too lazy/busy to test it out right now.