Related ticket: ⚓ T72 Whonix Greeter
About 100 MB will be added if main stream input methods are supported in Whonix. Is this acceptable?
user@chinese-im:~$ sudo apt-get install --no-install-recommends im-config ibus-pinyin ibus-anthy ibus-hangul ibus-unikey
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
anthy anthy-common dconf-cli gir1.2-ibus-1.0 ibus libanthy0 libhangul-data
libhangul1 libibus-1.0-5 liblua5.1-0 libpyzy-1.0-0v5
Suggested packages:
ibus-clutter ibus-doc ibus-qt4
Recommended packages:
kasumi
The following NEW packages will be installed:
anthy anthy-common dconf-cli gir1.2-ibus-1.0 ibus ibus-anthy ibus-hangul
ibus-pinyin ibus-unikey im-config libanthy0 libhangul-data libhangul1
libibus-1.0-5 liblua5.1-0 libpyzy-1.0-0v5
0 upgraded, 16 newly installed, 0 to remove and 3 not upgraded.
Need to get 21.6 MB of archives.
After this operation, 90.8 MB of additional disk space will be used.
I don’t come up with a reason to install input methods in Whonix-Gateway as user should never work in it.
For fronts, we may need them in both Whonix-Gateway and workstation.
About 130 MB will be added if multi-languages are supported in Whonix. Is this acceptable?
user@host:~$ sudo apt-get install --no-install-recommends locales-all fonts-kacst fonts-farsiweb xfonts-intl-chinese fonts-arphic-ukai fonts-arphic-uming fonts-wqy-microhei fonts-wqy-zenhei culmus libfribidi0 fonts-indic fonts-khmeros fonts-unfonts-core fonts-lao xfonts-bolkhov-koi8r-75dpi xfonts-bolkhov-koi8r-misc xfonts-cronyx-koi8r-100dpi fonts-lklug-sinhala fonts-thai-tlwg
Reading package lists... Done
Building dependency tree
Reading state information... Done
libfribidi0 is already the newest version (0.19.7-1+b1).
libfribidi0 set to manually installed.
locales-all is already the newest version (2.24-11+deb9u3).
locales-all set to manually installed.
The following additional packages will be installed:
fonts-beng fonts-beng-extra fonts-deva fonts-deva-extra fonts-gargi fonts-gubbi fonts-gujr fonts-gujr-extra fonts-guru fonts-guru-extra fonts-kalapi fonts-knda fonts-lohit-beng-assamese
fonts-lohit-beng-bengali fonts-lohit-deva fonts-lohit-gujr fonts-lohit-guru fonts-lohit-knda fonts-lohit-mlym fonts-lohit-orya fonts-lohit-taml fonts-lohit-taml-classical fonts-lohit-telu fonts-mlym
fonts-nakula fonts-navilu fonts-orya fonts-orya-extra fonts-pagul fonts-sahadeva fonts-samyak-deva fonts-samyak-gujr fonts-samyak-mlym fonts-samyak-taml fonts-sarai fonts-smc fonts-taml fonts-telu
fonts-telu-extra fonts-tlwg-garuda fonts-tlwg-garuda-ttf fonts-tlwg-kinnari fonts-tlwg-kinnari-ttf fonts-tlwg-laksaman fonts-tlwg-laksaman-ttf fonts-tlwg-loma fonts-tlwg-loma-ttf fonts-tlwg-mono
fonts-tlwg-mono-ttf fonts-tlwg-norasi fonts-tlwg-norasi-ttf fonts-tlwg-purisa fonts-tlwg-purisa-ttf fonts-tlwg-sawasdee fonts-tlwg-sawasdee-ttf fonts-tlwg-typewriter fonts-tlwg-typewriter-ttf
fonts-tlwg-typist fonts-tlwg-typist-ttf fonts-tlwg-typo fonts-tlwg-typo-ttf fonts-tlwg-umpush fonts-tlwg-umpush-ttf fonts-tlwg-waree fonts-tlwg-waree-ttf
Suggested packages:
xfs | xserver xfonts-intl-chinese-big xfonts-cjk emacs-intl-fonts
Recommended packages:
fonts-kacst-one
The following NEW packages will be installed:
culmus fonts-arphic-ukai fonts-arphic-uming fonts-beng fonts-beng-extra fonts-deva fonts-deva-extra fonts-farsiweb fonts-gargi fonts-gubbi fonts-gujr fonts-gujr-extra fonts-guru fonts-guru-extra fonts-indic
fonts-kacst fonts-kalapi fonts-khmeros fonts-knda fonts-lao fonts-lklug-sinhala fonts-lohit-beng-assamese fonts-lohit-beng-bengali fonts-lohit-deva fonts-lohit-gujr fonts-lohit-guru fonts-lohit-knda
fonts-lohit-mlym fonts-lohit-orya fonts-lohit-taml fonts-lohit-taml-classical fonts-lohit-telu fonts-mlym fonts-nakula fonts-navilu fonts-orya fonts-orya-extra fonts-pagul fonts-sahadeva fonts-samyak-deva
fonts-samyak-gujr fonts-samyak-mlym fonts-samyak-taml fonts-sarai fonts-smc fonts-taml fonts-telu fonts-telu-extra fonts-thai-tlwg fonts-tlwg-garuda fonts-tlwg-garuda-ttf fonts-tlwg-kinnari
fonts-tlwg-kinnari-ttf fonts-tlwg-laksaman fonts-tlwg-laksaman-ttf fonts-tlwg-loma fonts-tlwg-loma-ttf fonts-tlwg-mono fonts-tlwg-mono-ttf fonts-tlwg-norasi fonts-tlwg-norasi-ttf fonts-tlwg-purisa
fonts-tlwg-purisa-ttf fonts-tlwg-sawasdee fonts-tlwg-sawasdee-ttf fonts-tlwg-typewriter fonts-tlwg-typewriter-ttf fonts-tlwg-typist fonts-tlwg-typist-ttf fonts-tlwg-typo fonts-tlwg-typo-ttf fonts-tlwg-umpush
fonts-tlwg-umpush-ttf fonts-tlwg-waree fonts-tlwg-waree-ttf fonts-unfonts-core fonts-wqy-microhei fonts-wqy-zenhei xfonts-bolkhov-koi8r-75dpi xfonts-bolkhov-koi8r-misc xfonts-cronyx-koi8r-100dpi
xfonts-intl-chinese
0 upgraded, 82 newly installed, 0 to remove and 5 not upgraded.
Need to get 55.5 MB of archives.
After this operation, 130 MB of additional disk space will be used.
iry:
About 130 MB will be added if multi-languages are supported in Whonix. Is this acceptable?
Less (how much - dunno) in final downloadable image due to compression.
//cc @HulaHoop
kdesudo whonix-setup-wizard locale_settings
is not enough to let kde use another language. Related package also need to be installed (We don’t need all of them.):
user@host:~$ sudo apt-get install --no-install-recommends kde-l10n-
kde-l10n-ar kde-l10n-cavalencia kde-l10n-engb kde-l10n-fa kde-l10n-he kde-l10n-id kde-l10n-km kde-l10n-nb kde-l10n-pl kde-l10n-sk kde-l10n-ug
kde-l10n-ast kde-l10n-cs kde-l10n-eo kde-l10n-fi kde-l10n-hi kde-l10n-is kde-l10n-ko kde-l10n-nds kde-l10n-pt kde-l10n-sl kde-l10n-uk
kde-l10n-bg kde-l10n-da kde-l10n-es kde-l10n-fr kde-l10n-hr kde-l10n-it kde-l10n-lt kde-l10n-nl kde-l10n-ptbr kde-l10n-sr kde-l10n-wa
kde-l10n-bs kde-l10n-de kde-l10n-et kde-l10n-ga kde-l10n-hu kde-l10n-ja kde-l10n-lv kde-l10n-nn kde-l10n-ro kde-l10n-sv kde-l10n-zhcn
kde-l10n-ca kde-l10n-el kde-l10n-eu kde-l10n-gl kde-l10n-ia kde-l10n-kk kde-l10n-mr kde-l10n-pa kde-l10n-ru kde-l10n-tr kde-l10n-zhtw
I think multi-lang support is important especially if we want to cater to vulnerable populations that human rights groups are interested in which also makes funding proposals more attractive.
If possible I prefer cherry picking specific languages to maximize both global coverage and help censored areas. Another important point is if our install instructions have been translated into the respective language before bundling it. Without it then distro support is kinda pointless since they couldn’t install it in the first place.
There are excellent collaborative sites with huge communities that focus on translating libre software and related projects but their name escapes me. In the long-term we can have our wiki translated into a bunch of different languages. I would prioritize Mandarin/Pinyin, Russian and Spanish to cover huge swaths of the globe. Farsi and Arabic for human rights. No point with Korean because NK doesn’t have internet.
Most West Euro countries are anglo-lingual so supporting their respective language is a matter of national pride not necessity.
EDIT:
Translatewiki but the mediawiki translate extension was a total mess.
I couldn’t agree more.
Great idea. It seems the languages supported in Tails are somehow selected already. Do you think it is enough to cover those as language support?
There may be some south Korean activists, doing the work related to NK. But not sure if it is necessary. Maybe we can just support some languages and then hear the feedback from users.
Another great point! Although all the documentation should be translated into multi-language, some of documentation do have a high priority.
True! This problem can’t be resolved by mediawiki.
This page LocalizationLinguine · Wiki · Legacy / Trac · GitLab says:
There are many projects (Tor, Tails, F-Droid, SecureDrop, OnionShare, Riseup, EFF, etc.) and we want to create a single localization platform that we all share. This way the same community of translators can use a single site and help with all projects.
Maybe we can use it, too.
If it is okay, the first thing to do it figuring out how to backup/download all the Whonix Wiki pages automatically.
Yes this is a solid selection indeed.
+1 perhaps reaching out to Tor’s Ooni project to better assess the censorship landscape and who they view as priority is a good guideline.
Would be a fine project. Please keep an eye on it.
We already have instructions on how to download the wiki material AFAIK but nothing automated. Patrick mirrors a wiki archive every now and then to github but nothing on a regular schedule. A set of scripts to automate this would be very useful so we can seamelessly shuttle the latest documnetion over to a trasnlation platform as soon as there is a good choice.
PS. There are may great resources and idea in this topic please feel free to summarize them in a ticket on phabricator so they don’t get buried over time.
Whonix mediawiki backups are very up to date and automatic.
XML backups, mediawiki standard format, easy to restore on mediawiki.
Markdown based backup, no known way for automated restoration (mediawiki missing feature):
Related:
Environment Variables
export LANG=zh_CN.utf8 # available options can be found in locale -a
Fronts
sudo apt-get install --no-install-recommends locales-all fonts-kacst fonts-farsiweb xfonts-intl-chinese fonts-arphic-ukai fonts-arphic-uming fonts-wqy-microhei fonts-wqy-zenhei culmus libfribidi0 fonts-indic fonts-khmeros fonts-unfonts-core fonts-lao xfonts-bolkhov-koi8r-75dpi xfonts-bolkhov-koi8r-misc xfonts-cronyx-koi8r-100dpi fonts-lklug-sinhala fonts-thai-tlwg
Input Method
install
sudo apt-get install --no-install-recommends im-config ibus-pinyin ibus-anthy ibus-hangul ibus-unikey
settings
whonix-setup-wizard will call ibus-setup
, letting users choose it
manually.
We can also write a shell script that is auto-started and configure it
for user accroding to the $LANG.
Alternatively,
ibus engine pinyin # use 'ibus list-engine' to see all the engines
KDE
install
sudo apt-get install --no-install-recommends kde-l10n-ar kde-l10n-ru kde-l10n-zhcn
settings
whonix-setup-wizard will call kcmshell4 language
, letting users
choose it manually.
Thunderbird
install
sudo apt-get install \
thunderbird-l10n-ar \
thunderbird-l10n-ru \
thunderbird-l10n-zh-cn\
thunderbird-l10n-vi
settings
Thunderbird will:
--UILocale locale
Start with locale resources as User Interface locale. By
default, it is guessed from environment and available
locales for Thunderbird.
Therefore, set $LANG is enough. For example,
export LANG=zh_CN.utf8 # available options can be found in locale -a
Alternatively:
thunderbird -uilocale zh
I will write a script that will be auto-started when starting up Who nix-Workstation. It detects $LANG
:
- if the
$LANG
is set to a non-English available language, we simply configure to use the corresponding input method by calling:ibus-daemon -rxd && ibus engine pinyin
- If
$LANG
is English, we do not start ibus at all (Hopefully, this will mitigate the problem that too many input method icons will be shown in Qubes as only the workstations where a different$LANG
is set will cause the icon showing up.).
There are two questions remained to be resolved:
- I would like ibus not to be auto-started. However, I failed to figure out how to disable it. Could you please share some general methods on how to debug this?
- Since there are a lot of configuration and packages need to be installed. Should I create two new packages? e.g.
localization-gateway
andlocalization-gateway
and then set those two packages depend on IM and fronts packages?
Other issue which is not very important:
Unlike writing to dconf database, we start input method with a command line. This is because Whonix is using KDE, and dconf is more related to gnome. Even if apt-get install dconf-cli
, I still can’t figure out where the database is. A workaround is, for users who would like to use more than one engine, they can call kdesudo whonix-setup-wizard locale-settings
:
https://github.com/Whonix/whonix-setup-wizard/pull/8
//cc @Patrick
Why do we invent something here?
I mean… Would it be better to invoke the gui tools which are used by KDE, GNOME or other desktop environments? Do these exist?
iry:
Environment Variables
export LANG=zh_CN.utf8 # available options can be found in locale -a
Editing environment variables should not be done by distributions. It’s a hack. Last resort only.
Messing with LANG has a fair potential of introducing bugs such as:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "",
LC_ALL = (unset),
LANG = "de.utf8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
I don’t fully understand locale
. Please research. Please have a look at these files:
ls /var/lib/dpkg/info/locales*
See:
https://wiki.debian.org/Locale
Only developers should run dpkg-reconfigure locales
manually - for users it is too confusing.
dpkg-reconfigure locales
is the tool to do it manually. What program does it actually start? Where’s the code for that?
Can dpkg-reconfigure locales
be used by scripts? (So whonix-setup-wizard can automate that.)
dpkg-reconfigure locales
seems to modify:
- /etc/default/locale
- /etc/locale.gen
(I found that out by git committing all files inside /etc before running the tool, then running the tool, and then viewing the diff.)
Then it might run sudo locale-gen
which might be redundant because we are already installing Debian package locales-all
by default. So perhaps that is all there is to it.
Getting locales
right should sort out the environment variable automatically. Otherwise how is that variable set by upstream?
Whonix specific? Could this be put upstream?
iry:
- I would like ibus not to be auto-started. However, I failed to figure out how to disable it. Could you please share some general methods on how to debug this?
Check for new files in
/etc/xdg/autostart
/lib/systemd
/etc/profile.d
/etc/X11/Xsession.d/
(Put them under git version control to see new files after package
installation.)
Or check apt-file list pkg-name
for newly installed packages.
- Since there are a lot of configuration and packages need to be installed. Should I create two new packages? e.g.
localization-gateway
andlocalization-gateway
and then set those two packages depend on IM and fronts packages?
Add to anon-meta-packages.
Merged but then removed. This would result in having it installed inside Qubes-Whonix which would do nothing but waste space?
Also the technical background of Debian Packages - Whonix is very messy. Meaning no one would be able to ever remove these language packages without being affected by that mess.
Could you make it a weak dependency
please? (the forum search explains this term a bit) Basically:
- install from https://github.com/Whonix/Whonix/blob/master/build-steps.d/1700_install-packages (similar to
spice-vdagent
) - only modify
anon-shared-desktop-langpack-kde
- don’t make anything depend on
anon-shared-desktop-langpack-kde
That way we can skip the the package on Qubes and on Non-Qubes-Whonix it’s possible to skip during custom build and to uninstall in official builds.
Users who upgrade could manually install anon-shared-applications-kde
using instructions or whonix-setup-wizard could do it for them.
It’s necessary for Qubes-Whonix, too. For example, after installing these packages, the KDE user interface invoked by kdesudo whonix-setup-wizard locale_settings
can be shown in a different language, allowing user to do further localization settings.