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

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

stream_isolation:
  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:

## error_text: title="$(cat "/var/run/msgcollector/$who_ami/${identifier}.titlex")" 
## last exit_code: 1

No clue, so far.

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.

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:
https://github.com/troubadoour/msgcollector/commit/b412c6cdbec31dd7bf6079b0e554a4e49eab8410

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.

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.

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?

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.

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. http://en.irc2go.com/?q=tor.

Will have to find a way. In https://translatewiki.net/wiki/Translating:New_project, 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.

Sounds good.

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.