Bash commands are written in the Latin alphabet, is it possible to translate them to another language? In this case, Arabic. Arabic is written rtl and I remember I tried it using alias
before when I was little, what I'm asking is: is it possible to build another version of bash maybe (without using alias
), to translate the shell commands themselves, not the output?
2 Answers
Updated answer
NB: The original answer below was made to the initial version of the question, which wasn't being specific it was about commands instead of program messages.
Some facts:
The strings to be translated in GNU programs are not chosen by translators nor users, but by the developers.
There is a list of "things" to be translated in a program in the section 1.3 Aspects in Native Language Support of the GNU gettext manual. The following two points are related to the question, although they don't offer a prescribed course of action:
- Many programs read, interpret, compile, or are somewhat driven by input files which are texts containing keywords, identifiers, or replies which are inherently translatable. For example, one may want gcc to allow diacriticized characters in identifiers or use translated keywords; ‘rm -i’ might accept something else than ‘y’ or ‘n’ for replies, etc. Even if the program will eventually make most of its output in the foreign languages, one has to decide whether the input syntax, option values, etc., are to be localized or not.
- Almost all programs accept options, which are often worded out so to be descriptive for the English readers; one might want to consider offering translated versions for program options as well.
- The most common practice in most programs is that internal commands are not translated.
The original answer
There already exists a team with the Translation Project for Arabic. One of the translated projects ("domains") is bash
:
https://translationproject.org/domain/bash.html
Note: It looks that currently (2024-06-27) that specific domain has 0 translations, so if you'd like to volunteer, you can contact the team using the provided mailing list:
Sure, you can just go and translate all of bash
's commands; it's free and open source, exactly because you should be able to do whatever you like with it. It certainly would be a lot of work – the whole infrastructure in the bash source code to generate all the command parsing, self-documentation, and so on is assuming single-byte encodings for commands; but fixing things to support Unicode (more specifically, probably UTF-8) in these places as well, would probably be a good thing and uncover some bugs in "original" bash as well. The next question would be how much input methods (readline
etc) are married to the of left-to-right input. You might need to rewrite significant parts of the output routines, as the original terminals that bash targets were left-to-right devices. But this might already be a solved problem – I'm not able to type any right-to-left languages.
So, yes, possible, but a lot of effort with questionable return; my experience as someone who's used shells long before he was conversant in English is that shell commands are "symbols" anyways that you memorize, whether you speak the language or not. I'll argue that bash
is among the worst formal languages you could try to translate – no actual spec, you can never know whether a string is just "data" or going to be executed, no type system whatsoever that you could rely on, only useful in an ecosystem full of latin-lettered, English commands that you can't all translate; keywords are a concept, yes, but there's different keywords in different contexts and it's impossible to know in which context you are at any line before you've executed all the lines before: static analyis of bash scripts is essentially impossible, so simply translating the syntax might be very hard!
And: bash
is actively aiming for a very computer-savvyy audience. The people that are using bash
have already memorized so many concepts – what command line is, the idea of structured languages used to instruct computers, the correspondence of data, files and paths, … that the maybe 10, 20 most common bash builtins and commands will not be what stops them from using the shell. I'm extremely sympathetic of lowering the entry bar to computing, and extremely sympathetic of bringing technology and technology culture into more languages to make it less "English-centric". I'd just honestly look somewhere else: There's proper, structured programming languages where the distinction between keywords and identifiers is clear at any point. Such languages are used to teach people about structured thinking, a skill much more widely useful than shell usage (which you practically only need for computer administration, these days. There's millions of Linux users who haven't touched a shell). For example, many children today learn about the idea of structured instructions using scratch, which you can use in Arabic (Settings—> Language —> العربية). It switches screen layout, so that it makes sense when you work in a right-to-left writing system!
Achieving that right-to-left consistency in bash will essentially remain impossible – bash doesn't control the programs you invoke from it. Not to discourage you – but translating bash and all programs someone might invoke from it doesn't sound very feasible. So, I'd look for applications that aren't especially shells to general computing systems, but more specialized and that hence live in a more consistent environment. That might be GUI applications – for example, I have no idea how good the usability of spreadsheet applications is for a native Arabic speaker is. And things like spreadsheets are useful to very many people with far "thinner" background in "computer thinking" than shells. I know that LibreOffice has supportfor what is called "complex text layout". But there's a big difference between being able to read and type in a language, and displaying an interface which makes sense in that language.
bash
is written in theC
programming language, not English.min
,max
,list
,iterate
. Languages like java and others have tropes based on English (Token
vsTokenize
). An english speaker knows what the "ize" means, non-english speakers don't. Not all languages even have such mutations. I know Chinese doesn't.