Internationalization Support - bash scripts

[phabricator-migrator]

Information

ID: 83
PHID: PHID-TASK-q2ytnq3ap6thptawv56h
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal

Description

Add internationalization to Whonix’s bash scripts (whonixcheck etc.).

Inspiration:

• su-to-root which is part of the debian menu
• Tails
• /usr/bin/gettext.sh from package gettext-base
• Internationalizing Those Bash Scripts | Linux Journal

Comments

---

troubadour

2015-04-04 22:01:49 UTC

Or, using the same translation mechanism as whonix-setup-wizard.

• create a .yaml file for each whonixcheck step. Example /home/user/whonixcheck_10.yaml:

  en:
    functional:
      <p>Stream Isolation Test Result&#58; Functional. YEAAAHHH</p```
- new script `bash_message` or something like that:
```#!/usr/bin/python

import sys
from guimessages import translations

file_path = sys.argv[1]
section = sys.argv[2]
message = sys.argv[3]

translation = translations._translations(file_path, section)
_ = translation.gettext
print _(message)

• get whonixcheck messages as follow (example from check_stream_isolation):

      $output ${output_opts[@]} --messagecli --typecli "info" --message "$MSG"
      else	
         #local MSG="<p>Stream Isolation Test Result: Functional.</p>"
         ###########################################
	 local file_path="/home/user/whonixcheck_10.yaml"
	 local section="stream_isolation"
	 local msg="functional"
	 local MSG="$(/home/user/bash_message "$file_path" "$section" "$msg")"
         ###########################################
         $output ${output_opts[@]} --messagex --typex "info" --message "$MSG"

A big bonus would be to have a standard yaml files format for the people at translatewiki.

It works, almost. There is a strange issue (for me). whonixcheck reports an error with the new command:
## error_cause: error_handler signal ERR detected with BASH_COMMAND: /home/user/bash_message "$file_path" "$section" "$msg"

When running
bash -x whonixcheck --verbose
the message from /home/user/whonixcheck_10.yaml is displayed in the GUI (“YEAAAHHH” included), but some errors from msdispatcher:

## last exit_code: 1 ```
No clue, so far. 

---

troubadour

2015-04-05 05:12:02 UTC

The issue is fixed: access to bash_message was denied by AppArmor…

If we agree on this method, I could start porting all the bash scripts outputting user messages. Then, once a couple of them are done, contact translatewiki to start a Whonix translation project.

We should agree on a translation file name convention, ie whonixcheck_stream_isolation.yaml, tb_updater_gui.yaml and so on.

---

troubadour

2015-04-06 20:26:43 UTC

Started with three whonixcheck files.

Modified whonixcheck files:
https://github.com/troubadoour/whonixcheck/commit/8d52f23214ee3f30027ccf7bd9247db10831df3f

New translations files:
https://github.com/troubadoour/whonix-setup-wizard/commit/3ea74ae298fe625fd8aeda2fe4d27eead29a9f94
There is an extra commir (fix missing new lines).

The colons used in the yaml text have to be declared with their html ASCII code. Convert back to : for the cli:
convert yaml colons ':' to ':' for cli · troubadoour/msgcollector@b412c6c · GitHub

---

Patrick

2015-04-07 12:06:47 UTC

Nice!

I’ll look more throughly soon.

Since local always returns 0, and we’re using something more complex now than a simple string setting, we need to split it up. Instead of.

local MSG="$(/usr/share/pyshared/guimessages/bash_message [...]

We need to switch to this.

local MSG
MSG="$(/usr/share/pyshared/guimessages/bash_message [...]

For better readability, the local deceleration could also be mixed with other, former local declarations. I mean, if there are any in that function above. Not very important, just refactoring. I.e. local var1 var2 MSG etc.

---

Patrick

2015-04-10 14:28:47 UTC

! In T83#3553, @troubadour wrote:
If we agree on this method, I could start porting all the bash scripts outputting user messages. Then, once a couple of them are done, contact translatewiki to start a Whonix translation project.

We should ask translatewiki if they like our way at all. Perhaps just start small and simple with whonix-setup-wizard. I want to prevent the possible (although not likely) desaster, that we finish this just to learn at the end that we need to start again, because translatewiki doesn’t like our approach.

We should agree on a translation file name convention, ie whonixcheck_stream_isolation.yaml, tb_updater_gui.yaml and so on.

Yes.

---

Patrick

2015-04-10 14:40:17 UTC

Looks very good overall.

When this is mergeable (let’s start small with just a few translated messages), I can do the refactoring with local. Really a minor, easy task. Kinda as a template for further porting.

The following is non-ideal, but easy to improve…

local file_path="/usr/share/translations/whonixcheck_control_port_filter.yaml"

Apart from the local it would be better to make /usr/share/translations a variable such as $translations_path that gets set in preparation()? But that’s minor and easily doable by me after the first small merge.

Also I am unsure if /usr/share/translations/ is a valid path as per FHS and Debian policy. Perhaps it should be rather /usr/share/${pkg-name}/translations/. Would be good to get this right from the start so stuff like this wouldn’t block later upstreaming to Debian (unlikely for whonixcheck, whonix-setup-wizard, but more likely for other packages).

Maybe we should prefix variables with t_, i.e. t_file_path?

---

Patrick

2015-04-10 14:59:42 UTC

For scalability, I think putting whonixcheck’s messages into whonix-setup-wizard package is confusing and wrong. whonixcheck should ship that messages itself and have a dependency on python-guimessages.

---

troubadour

2015-04-10 18:15:22 UTC

! In T83#3580, @Patrick wrote:
We should ask translatewiki if they like our way at all. Perhaps just start small and simple with whonix-setup-wizard. I want to prevent the possible (although not likely) desaster, that we finish this just to learn at the end that we need to start again, because translatewiki doesn’t like our approach.
Yes, that’s the first think to do before contuining. I am trying to contact translatewiki. The best - and perhaps only - mean seems to be IRC. The problem is that they are on freenode (#mediawiki-i18n), which bans Tor. They have a hidden service (difficult to know which one is current) but it’s disabled at the moment. Internet Relay Chat (IRC).

Will have to find a way. In Translating:New project - translatewiki.net, email is specified, but without a link. I will have to try from the host, behind a VPN (if that’s good enough, I do not know). I have registered a nick already.

Also I am unsure if /usr/share/translations/ is a valid path as per FHS and Debian policy. Perhaps it should be rather /usr/share/${pkg-name}/translations/. Would be good to get this right from the start so stuff like this wouldn’t block later upstreaming to Debian (unlikely for whonixcheck, whonix-setup-wizard, but more likely for other packages).

For scalability, I think putting whonixcheck’s messages into whonix-setup-wizard package is confusing and wrong. whonixcheck should ship that messages itself and have a dependency on python-guimessages.

Yes to both. The first commits were for say, presentation. I was thinking of a separate translations package, but /usr/share/${pkg-name}/translations looks better. Each package with its own translation files is probably the way.

---

Patrick

2015-04-12 15:05:43 UTC

Sounds good.

---

Patrick

2015-04-12 15:11:21 UTC

On a second thought, I am wondering about performance. Currently for all messages added to msgcollector, two blocking process forks are done (for cli and gui). By running bash_message before, two more blocking process forks are added. It might very well be negligible. Probably doesn’t matter if whonixcheck ~3 more seconds.