I’ve had this topic in my blog queue for a couple of weeks but I noticed literally scores of tweets pointing to the post in question. That was enough to make me forego my own post on the subject but on rereading the original post, I realized there are some good ideas in it regardless of what’s going on with the tweets.
The post, by Dylan Kirby of MojoTech, discusses to problem of internationalizing text strings in an application that will be used in more than one country. Kirby discusses the problem in terms of the React framework but almost exactly similar problems occur anywhere you need internationalization. I’ve done my share of that in C where we used the GNU gettext library. It’s always a pain and, truth to tell, I avoided working on it whenever I could slough it off to my colleagues. I’m a bad person, I know.
Regardless, Kirby and his colleagues were stuck with doing it and he noticed that it was mostly repetitive work. They used Google Translate to provide a first order translation that was later refined by a human translation service so a first hack at the translation could be automated along with the rest of the mechanics.
You can get the details from Kirby’s post but the most important lesson from his account for me is that it serves as an answer to why you might prefer an Emacs “lisp-machine-like” environment to the pure editing environment of Vim. Kirby’s problem is representative of a common class of problems that are easy to automate with Emacs. My Vim-foo is rusty enough that I don’t see an easy way to do the same thing in Vim, especially the querying of Google Translate. You can argue that you don’t want to read emails in Emacs or use it to listen to music but, believe me, if you have to deal with internationalization, you’ll be happy to have a way of automating it as much as possible. It’s just one more reason that I’m glad to be an Emacs user.