It looks like you're new here. If you want to get involved, click one of these buttons!
Working from a command line interface (CLI) is experiencing a comeback ... over the last 20 years as a teacher in SW and HW for designers and artists, I have experienced an evolution of the tools that seems to be bringing SW creators (even the occassional developer) back to CLI and away from the UI.
In late 2015 I wanted to contribute to the work done in the hacking of FPGAs, in particular to project IceStorm. Back then I was in the middle of writing my PhD and I needed a break for a couple of days after getting one of my chapters rejected for the third time. Contributing to an open source project felt like a great way to recharge batteries.
For those not informed about the development of those tools. Field programmable gate arrays (FPGAs) are chips with no pre-loaded computing architecture. Microcontrollers, for example, come with a pre-loaded CPU, programs can be written on top of the CPUs commands. FPGAs allow to create your own CPUs. FPGA vendors' business consist in selling not just the chips, but also the programming tools (SW + HW), and development kits. Therefore, opening up any part of the process (as in open sourcing) is considered bad for business, since there is some money that will be made by someone else instead of the vendors.
A couple of years ago, and thanks to the effort of Claire Wolf (creator of IceStorm), several tools emerged that allowed creating code for a specific brand of FPGAs. Reverse engineering the bitcode to the FPGAs they opened for the possibility of people writing their own IDEs to create their own computing architectures.
I decided to contribute to this project because I knew one of the main contributors to the examples around IceStorm and creator of the Alhambra board, Juan Gonzalez Gomez, aka Obijuan. I looked at making the installation of the software and Obijuan's examples easier for those not speaking English, by creating the following repository:
In order to make this happen, I used the following article from 2010 on how to localize bash scripts:
The work done here was based on the idea that people should have an easy time installing from CLI and that having all of the messages in their own language should reduce the friction in that process. It took two years before I got a comment on how to improve the software (and I didn't notice until I started writing this post, 2 years later).
The mechanism for doing the BASH translation is done through calls to
i18n_display "your text string here"
The text string will be translated -on the fly- by taking it from the localization files under the translations subfolder.
The structure of those translation files looks as follows:
There you can see how
msgid indicates the identifier to the string to be translated, while
msgstr is the string in the translation language.
Years after having made this work, and despite its little success, I still wonder about the pedagogical value of prompting people about what is that their installation scripts are doing when installing things. If I create a tool and want to deploy it, I could write an article on my blog and explain the step by step operations needed to install all of the dependencies needed, or I could write a good BASH script that could be taken over others and translated to multiple languages.
In the beginning there was the command line by Neal Stephenson
Project IceStorm: http://www.clifford.at/icestorm/
Clifford on programming style: http://www.clifford.at/style.html (could be enough for another post)