In whonixsetup disclaimer, do we have to give the German version? I remember reading somewhere that there was some legal issue.
Edit by Patrick:
Changed title.
Yes.
I am wondering if we should refactor whonixsetup first. By putting the text’s into their own text files?
Yes, as a resource to the scripts, probably. That would make the code cleaner (in whonix-repository-wizard too) and the text modifiable externally.Yes, as a resource to the scripts, probably. That would make the code cleaner (in whonix-repository-wizard too) and the text modifiable externally.
As a related question, how do we make those translateable in future? Do we shoot ourself into the feet by putting them into custom txt files?
At some point for the bash scripts I wanted to do it similar as Tails does (pretty standard approach, I think) and use gettext to make them translateable.
Even though it’s mostly shell script, do you like to look into this?
Even though it's mostly shell script, do you like to look into this?
There is the gettext module in python. After the declaration, it’s a question of syntax.
print _('some text') We can easily use it as standard.
Ideally we could use reuse the translated strings for whonixsetup as well as whonixsetup wizard. But it’s not a must.
We could also leave whonixsetup as is without translating it for CLI users and have a completely code independent gui whonixestup wizard.
We could also leave whonixsetup as is without translating it for CLI users and have a completely code independent gui whonixestup wizard.
That was my next question. Yes, it would make sense. Pushing further, why not have two separate wizards? One for gateway, integrating bridge setup, one for workstation, launching update-torbrowser if the user wants to install Tor Browser during installation. That should be feasible.
Currently whonixsetup asks different stuff on gw than on ws.
I am wondering what is better…
Both in one package + if/else magic?
[In mid term future three in one - when implementing Whonix host https://github.com/Whonix/Whonix/issues/39]
Or…
Two [three] separate packages?
I would prefer two[three] separate packages. Decreasing the if levels makes the code more maintainable.
With that option, what about bridges and update-torbrowser?
update-torbrowser:
Not sure if that is needed. When they are going to start Tor Browser and it’s not installed, it will ask if it shall be downloaded anyhow. Also it’d need some kind of “what if tb-updater is not installed” handling as well as an option to skip - some may not want to use Tor Browser in that VM (if they use a separate one for a server or so). (I mean, it shouldn’t imply it’s an important step.) But possible. You decide.
Please keep https://github.com/Whonix/Whonix/issues/346 in mind as well.
Bridges:
Yes, simplification would be nice.
Prerequisite knowledge…
- I am trying to make more generic answers for others to keep up with our tech talk, even you may know the following already.
- tor-launcher is different from torbrowser-launcher. See also: Tor Browser Essentials
I think using tor-launcher would be better than re-inventing this? ( https://github.com/Whonix/Whonix/issues/167 ) (The nice wizard TBB is using. We could re-use this.)
The bridge wizard otherwise can become quite a maintenance and support heavy thing. It may look easy at first, but the devil is in the detail (config writing, user broken config entries, broken bridges) and in future constantly new transport options will come up (from TPO), I guess. So if you could work on that as well?
What do you think?
[quote=“Patrick, post:4, topic:650”]As a related question, how do we make those translateable in future? Do we shoot ourself into the feet by putting them into custom txt files?
At some point for the bash scripts I wanted to do it similar as Tails does (pretty standard approach, I think) and use gettext to make them translateable.
Even though it’s mostly shell script, do you like to look into this?[/quote]
I also wrote a custom function in python that could be used to store the translations all in one file. Looks at [url=https://github.com/nrgaway/linux-template-builder/blob/wheezy/scripts_debian/wheezy%2Bwhonix-gateway/files/usr/lib/whonix/messages.yaml]https://github.com/nrgaway/linux-template-builder/blob/wheezy/scripts_debian/wheezy%2Bwhonix-gateway/files/usr/lib/whonix/messages.yaml[/url] for the translation file and [url=https://github.com/nrgaway/linux-template-builder/blob/wheezy/scripts_debian/wheezy%2Bwhonix-gateway/files/usr/lib/whonix/alert]https://github.com/nrgaway/linux-template-builder/blob/wheezy/scripts_debian/wheezy%2Bwhonix-gateway/files/usr/lib/whonix/alert[/url] for its implementation;
Implementation
#!/usr/bin/python
#
# Copyright 2014 Jason Mehring (nrgaway@gmail.com)
#
from PyQt4 import QtGui
import locale
import yaml
DEFAULT_LANG = 'en'
class Messages():
filename = None
data = None
language = DEFAULT_LANG
title = None
icon = None
message = None
def __init__(self, section, filename):
self.filename = filename
language = locale.getdefaultlocale()[0].split('_')[0]
if language:
self.language = language
try:
stream = file(filename, 'r')
data = yaml.load(stream)
if section in data.keys():
section = data[section]
self.icon = section.get('icon', None)
language = section.get(self.language, DEFAULT_LANG)
self.title = language.get('title', None)
self.message = language.get('message', None)
except (IOError):
pass
except (yaml.scanner.ScannerError, yaml.parser.ParserError):
pass
class WhonixMessageBox(QtGui.QMessageBox):
def __init__(self, message):
super(WhonixMessageBox, self).__init__()
self.message = message
self.initUI()
def initUI(self):
message = self.message
if message.title:
self.setWindowTitle(message.title)
if message.icon:
self.setIcon(getattr(QtGui.QMessageBox, message.icon))
if message.message:
self.setText(message.message)
self.exec_()
import argparse
import sys
def main():
parser = argparse.ArgumentParser(description='Display a QT Message Box')
parser.add_argument('section', help="Message section")
parser.add_argument('filename', help="File including full path")
args = parser.parse_args()
if not args.filename and args.section:
print parser.usage()
sys.exit(1)
app = QtGui.QApplication(sys.argv)
message = Messages(args.section, args.filename)
dialog = WhonixMessageBox(message)
sys.exit()
if __name__ == "__main__":
main()Translation file
update:
icon: Critical
en:
title: Tor netvm required for updates
message: |
<p><B>Tor netvm required for updates!</B></p>
<p>Please ensure your template vm has a Whonix gateway as it's VM.</p>
<p>No updates are possible without an active (running) Whonix gateway VM.</p>
<p/>
<p><b>Template will now power off</b></p>Thanks for the input, this is great ! Not only for the translations.
I wrote a script “generic_gui_message” called from a few places in Whonix bash scripts. We give all the QMessageBox arguments from there. With yaml, we can just pass the section in messages.yaml.
@Patrick.
How does that sound? We do not touch cli and we can be as verbose as we like in the GUI environment.
Leaving that to your judgment.
[hr]
Another reason for just 1 package:
You can share more common code / questions.
Alternatively, if you prefer two packages, why not three? Perhaps these common code / messages (disclaimer, language selector) could go into a whonix-(gw|ws|shared)-setup(-???) package?
Just saying, I don’t want to convince you.
[hr]
Would you like to put https://github.com/Whonix/Whonix/issues/15 also into whonixsetup wizard? Nevermind about that. We can also do that much later.
[hr]
Another obvious comment I have, I would like to have whonixsetup wizard being as brain dead “click though” as whonixsetup. I mean, for someone who accepts the disclaimers, uses ENG/US, wants to use Whonix stable repo, connects to the public Tor network (the most common defaults), they’d only need to click “next”.
Sounds good.
If we implement the bridge option, do we have to give the optional pluggable transports too? Yes, the list is growing.That should be up to tor-launcher? And tor-launcher supports pluggable transports quite well.
Since many of those pluggable transports are not yet in Debian, I was thinking if it would make sense to download TBB on Whonix-Gateway as well, to be able to use it’s tor-launcher (add-on), Tor and pluggable transports. ( Related to: https://github.com/Whonix/Whonix/issues/53 )
Struggling with the wizards. Getting clearer now.
It looks like we’ll be able to put whonixsetup GUI tool for Gateway and Workstation in a single script/package, without ending with an overly complicated logic (split at page level instead of wizard level).
The packages plan (provisional):
Wizards: 2 packages.
- /usr/bin/whonixsetup-wizard (or whonixsetup-gui-tool?)
- /usr/bin/whonix-repository-wizard (or whonix-repository-gui-tool?)
Common scripts: 1 package.
- guimessage.py
- translations.py
in /usr/lib/python2.7/dist-packages/whonix-common.
Translations file: 1 package.
- /usr/share/whonix/whonix-shared-translations
How does that sound?
Good.
The packages plan (provisional): [u]Wizards[/u]: 2 packages. - /usr/bin/whonixsetup-wizard (or whonixsetup-gui-tool?) - /usr/bin/whonix-repository-wizard (or whonix-repository-gui-tool?)I like -wizard more, but perhaps others disagree/have other suggestions. (Guess not, we raised this before.) You decide.
[u]Common scripts[/u]: 1 package. - guimessage.py - translations.pyYes. How to name that package? python-guimessage? Or something else?
in /usr/lib/python2.7/dist-packages/whonix-common.The path is a bit non-ideal. guimessage.py and translations.py doesn't sound Whonix/anon specific at all. What about /usr/lib/python2.7/dist-packages/python-guimessage?
[u]Translations file[/u]: 1 package. - /usr/share/whonix/whonix-shared-translationsTranslations belong into the respective package, i.e. whonixsetup-wizard /usr/share/whonixsetup-wizard/[translations] or whonix-repository-wizard?
[quote=“Patrick, post:16, topic:650”][quote]The packages plan (provisional):
Wizards: 2 packages.
- /usr/bin/whonixsetup-wizard (or whonixsetup-gui-tool?)
- /usr/bin/whonix-repository-wizard (or whonix-repository-gui-tool?)[/quote]
I like -wizard more, but perhaps others disagree/have other suggestions. (Guess not, we raised this before.) You decide.[/quote]
Let’s keep it -wizard.
[quote][u]Common scripts[/u]: 1 package. - guimessage.py - translations.py[/quote] Yes. How to name that package? python-guimessage? Or something else?"python-guimessages" would do. These two scripts handle both the message boxes and the text from the wizards. /usr/lib/msgcollector/generic-gui-message should be replaced by guimessage.py. For example, the warning issued by open-link-confirmation would become translatable..
[quote]in /usr/lib/python2.7/dist-packages/whonix-common.[/quote] The path is a bit non-ideal. guimessage.py and translations.py doesn't sound Whonix/anon specific at all. What about /usr/lib/python2.7/dist-packages/python-guimessage?Same as above: /usr/lib/python2.7/dist-packages/python-guimessages.
[quote] [u]Translations file[/u]: 1 package. - /usr/share/whonix/whonix-shared-translations [/quote] Translations belong into the respective package, i.e. whonixsetup-wizard /usr/share/whonixsetup-wizard/[translations] or whonix-repository-wizard?No. The translations file belong to both wizards (and to the messages boxes). It would be updated each time we add a new functionality to the wizards, or a new gui warning.
"python-guimessages" would do. These two scripts handle both the message boxes and the text from the wizards. /usr/lib/msgcollector/generic-gui-message should be replaced by guimessage.py. For example, the warning issued by open-link-confirmation would become translatable..To avoid code duplication, rather than replacing /usr/lib/msgcollector/generic-gui-message it would be better if scripts currently relying on /usr/lib/msgcollector/generic-gui-message would be ported to use python-guimessages. Maybe this is what you meant.
No. The translations file belong to both wizards (and to the messages boxes). It would be updated each time we add a new functionality to the wizards, or a new gui warning.That one I don't understand. Why that? For simplicity? Are there shared messages? Why aren't the files for translations of different tools not separated?
Let’s frame it like this… Someone not using Whonix, a Debian dev gets interested to use non-Whonix/anon specific, generic python-guimessage as a lib. Would you have to tell, “oh well, but if you want to add translations, those should go into whonix-shared-translations package”? Would be kinda illogical?
Wouldn’t it be better if someone using python-guimessage could configure the path where translations are located?
To avoid code duplication, rather than replacing /usr/lib/msgcollector/generic-gui-message it would be better if scripts currently relying on /usr/lib/msgcollector/generic-gui-message would be ported to use python-guimessages. Maybe this is what you meant.[/quote]
Ye, that is what I mean. I see no problem porting the bash scripts using python-guimessage.
[quote]No. The translations file belong to both wizards (and to the messages boxes). It would be updated each time we add a new functionality to the wizards, or a new gui warning.[/quote] That one I don't understand. Why that? For simplicity?Yes.
Are there shared messages? Why aren't the files for translations of different tools not separated?They can be separated. Will have to pass a second parameter (file name) to translations.py. Not a big deal.
Let's frame it like this... Someone not using Whonix, a Debian dev gets interested to use non-Whonix/anon specific, generic python-guimessage as a lib. Would you have to tell, "oh well, but if you want to add translations, those should go into whonix-shared-translations package"? Would be kinda illogical?I was not seeing that far. For the time being, I am coding for Whonix, but it is possible to make the package more versatile.
Wouldn't it be better if someone using python-guimessage could configure the path where translations are located?The file name parameter in guimessge.py and tranlations.py should take care of that.
Finally, if we package a translation file with each wizard, it does make sense to revert to the original architecture: script and .yaml file in /usr/lib/python2.7/dist-packages/wizard-name, the executable in /usr/bin, importing and running the module.
I was not seeing that far. For the time being, I am coding for Whonix, but it is possible to make the package more versatile.Ok, great. I am not insisting on this approach, though. Just having best practices, clean code, easy re-usability and such in mind. Makes the code more readable and Whonix overall more logical, understandable, extensible, auditable and so forth. I mean, in past there were no separate Whonix packages, all files were in whonix_(gateway|workstation|shared) folder. Technically it was not the slightest bit less safe, but difficult to get into for newcomers, and now much more grasp and work on Whonix.