Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Guests: Kayla Adams * Sophia Beall * Daisy Bell * Hope Carpenter * Dimitrios Chavouzis * Esha Chekuri * Tucker Craig * Alec Fisher * Abigail Floyd * Thomas Forman * Emily Fuesler * Luke Greenwood * Jose Guaraco * Angelina Gurrola * Chandler Guzman * Max Li * Dede Louis * Caroline Macaulay * Natasha Mandi * Joseph Masters * Madeleine Page * Mahira Raihan * Emily Redler * Samuel Slattery * Lucy Smith * Tim Smith * Danielle Takahashi * Jarman Taylor * Alto Tutar * Savanna Vest * Ariana Wasret * Kristin Wong * Helen Yang * Katherine Yang * Renee Ye * Kris Yuan * Mei Zhang
Code Critique: internationalization of BASH scripts
Prelude
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.
The story
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:
https://github.com/dcuartielles/open-fpga-install/
In order to make this happen, I used the following article from 2010 on how to localize bash scripts:
https://www.linuxjournal.com/content/internationalizing-those-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.
The questions
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.
- Do you feel, like I do, that CLI is coming back and that it is not that crazy to make the whole installation as a script, so that the actions and the documentation can be put in a format where it is easier to contribute to?
- Which are the limitations offered by the sharing interface (Github in this case) towards other communites, how would a translation process look like?
- Should it be workshops with potential community participants?
- Would you, as a user of one of BASH scripts, find useful to understand what happens when you call the different actions? Or would you prefer a non-running environment (like a blog) where to read about it instead?
- Have you ever installed a series of packages from CLI? How was your experience?
Recommended readings
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)
Comments
@dcuartielles -- Thanks for sharing this project. It seems like a great effort, even if it didn't get the uptake you hoped. The article "Internationalizing Those Bash Scripts"[1] was very interesting.
When I tried to take a quick look at the supporting i18n shell tools that this approach builds on I discovered that they are not installed in macOS 12.x -- this is a not a showstopper for me, as I am familiar with homebrew installs...
...but I imagine that the missing dependencies (plus the need to manually link) are an extra barrier to entry for new users if they happen to be on the wrong operating system. Further, it isn't just the translators / "localizers" who need those installs, it is any user of the software that relies on them, as they become a required dependency.
From the macOS side, I am not currently running the latest (macOS 10.15 Catalina), but it looks like even the latest version is still not incorporated those i18n tools by default. Instead, the situation may have gotten worse for some rather than better recently, with gettext failing to build in mac dev tools, causing cascading failures for dependent software ("It looks like gettext won’t build under Xcode 11 (tried beta 6 and beta 7). [...] Since gettext is a dependency of ungodly lots of stuff, this hurts").
So, when I think about whether I would incorporate this into my own projects as a kind of design pattern, that is my main hesitation -- that so much of whether the effort succeeds or fails might depend on default OS-level support.
Re:
I do feel like CLI is coming back... although in broader culture perhaps its sharpest drop-off was in the 1990s, and comeback-with-a-difference has been gradually happening over the past two decades. In some ways the "command line" era was supplanted by the "desktop" era which then became a "search bar" era -- and the search bar paradigm was a much a better conceptual on-ramp to a command-line than the Xerox PARC desktop metaphor or the hypertext link. But my feelings about this are complicated. Many of my students today are less interested in the underpinnings of software systems, which they consider so rapidly changing as to be ephemeral. In some ways they are right to be skeptical of investing in learning the internals of things that are so transient. I also find that students who are fairly adept and ambitious with software -- mobile power users, media makers, designers -- can surprise me by being unfamiliar with core concepts of command line / OS paradigms, such as file dates or file extensions or even directory structures. This makes sense if the software that they use daily is hiding those aspects of their OS from them as implementation details -- why should they know what a file extension is? But it does mean that in at least one way the gap for new command line users may have widened recently rather than closed.
Iacona, Louis J. "Internationalizing Those Bash Scripts." Linux Journal. September 27, 2010. https://www.linuxjournal.com/content/internationalizing-those-bash-scripts ;↩︎