[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Chinese fonts and input method


#9

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.

#10

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


#11

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

#12

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.


#13

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:

https://translatewiki.net/
http://zanata.org/


How to install Chinese fonts and input method in whonix13
#14

Translatewiki but the mediawiki translate extension was a total mess.


#15

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. :slight_smile:

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 https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/Notes/LocalizationLinguine 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.


#16

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.


#17

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:


#18

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

#19

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:

  1. 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?
  2. Since there are a lot of configuration and packages need to be installed. Should I create two new packages? e.g. localization-gateway and localization-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:

//cc @Patrick


#20

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?


#21

iry:

  1. 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.

  1. Since there are a lot of configuration and packages need to be installed. Should I create two new packages? e.g. localization-gateway and localization-gateway and then set those two packages depend on IM and fronts packages?

Add to anon-meta-packages.


#22

Thank you so much for teaching me about this, @Patrick !



#23

Merged but then removed. This would result in having it installed inside Qubes-Whonix which would do nothing but waste space?


#24

Also the technical background of https://www.whonix.org/wiki/Whonix_Debian_Packages 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:

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.


#25

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.


#26

Finally, sorted out!

The proper way to configure input method is using im-config. This is how it works from man im-config:

The im-config package installs a hook script /etc/X11/Xsession.d/70im-config_launch. When X starts, it sources this file as a POSIX shell code. Then this hook script tries to source the user configuration file ~/.xinputrc, if it exists.

My understanding is:

  • Input method (ibus) should only be install in Whonix-Workstation, not Whonox-Gateway as it is not the place to work.
  • For Qubes-Whonix, We don’t want the ibus icon to be shown for every VM started. Because it is not only against Qubes policy, but also makes the interface messy by having a bunch of similar looking icons.
  • For non-Qubes-Whonix, it is okay to start ibus by default as a single icon does not hurt anybody and allows easier input method configuration.

By default, ibus will be used by im-config. Therefore:

  • in Qubes-Whonix case, we need to execute im-config -n none after the installation of ibus and im-config. And let user who needs ibus use im-config -n ibus.
  • in non-Qubes-Whonix, we need to do nothing.

Alternatively, a platform interdependent solution is only invoking ibus when the $LANG is set to a different and available language. /usr/share/im-config/data/02_cjkv.rc is shipped with im-config for this purpose. We simply change ~/.xinputrc to:

user@language:~$ cat ~/.xinputrc
# start most popular available input method automatically
# for Chinese, Japanese, Korean, Vietnamese
case $LANG in
zh_*.*|ja_JP.*|ko_KR.*|vi_VN.*)
    run_im ibus
    ;;
*)
    run_im none
    ;;
esac

#27

It seems this doesn’t work with a TemplateBasedVM which is based on a TemplateVM with $LANG set to English. Even if we write export LANG='zh_CN.utf8' to ~/.bashrc, at the time ~/.xinputrc is executed, $LANG is still English.


#28

I see. Since we are a distribution please drop eventual required snippets into /etc/X11/Xsession.d and don’t write into the home folder. For your kind consideration:

Let’s not install it on Whonix-Gateway for now and listen to user feedback.

Correct.

It’s not great but acceptable. A first time wizard would be better to avoid this systray icon for those not needing it?

Seems better. Ought to avoid ~/.xinputrc home folder with more appropriate folder though.

Is xinputrc processed at all in Qubes?
A web search for "qubes" ".xinputrc" shows some results.
Maybe https://groups.google.com/forum/#!topic/qubes-users/VcNPlhdgVQM - didn’t throughly read.