1. 26 Mar, 2020 1 commit
    • intrigeri's avatar
      Switch Japanese input method from Anthy to Mozc (refs: #16719) · c56cd06b
      intrigeri authored
      A Japanese speaker (passis12345678) tells us that:
      
      "I don't think any Japanese users would agree that Anthy is better than Mozc.
      The accuracy of Mozy's Kanji conversion is clearly superior to that of Anthy.
      I’ve never seen or heard of anyone who likes Anthy.
      Any Japanese user would be happy to replace Anthy with Mozc."
      
      They also note that ibus-anthy has one advantage over ibus-mozc: it defaults to
      Japanese input, while ibus-mozc defaults to alphabetic and the user has to
      change the setting to Japanese every time they login. Despite that drawback,
      passis12345678 thinks that switching to Mozc is worth it anyway: it's
      a one-per-Tails-session annoyance, as opposed to a permanent annoyance while
      typing in Japanese.
      
      This would be fixed by fcitx-mozc (which defaults to Japanese), but switching to
      fcitx is another, much bigger matter: IBus seems to be much better integrated
      into GNOME than fcitx. Let's stick to IBus for now and try this minimal change.
      c56cd06b
  2. 11 Jul, 2019 2 commits
  3. 11 Mar, 2019 1 commit
  4. 11 Feb, 2016 2 commits
    • anonym's avatar
      Separate set -eu in to separate statements. · 0bd8d3a0
      anonym authored
      ... like we do in most places. This makes these highly relevant
      properties of the scripts a bit more easy to spot.
      0bd8d3a0
    • anonym's avatar
      Avoid set -u issue when testing if variable is set or not. · 364a3c8d
      anonym authored
      Whenever there's a risk that we will reference a shell variable in a
      script run with `set -u` (including libraries that we sources from
      such scripts) we must reference the variable in a way so it gets a
      default value, i.e. `${VAR:-}` to give it the empty string as the
      default (which is what generally makes sense).
      
      In particular, it's quite clear that in all cases where we do
      something like `[ -n "${VAR}" ]` or `[ -z "${VAR}" ]`, where an
      expected value is the empty string, which could mean that the variable
      is not initialized, we should give such a default (as the empty
      string).
      364a3c8d
  5. 30 Nov, 2015 1 commit
  6. 22 Nov, 2015 1 commit
  7. 09 Feb, 2015 1 commit
  8. 26 Nov, 2014 2 commits
  9. 15 Sep, 2014 1 commit
  10. 14 Sep, 2014 1 commit
  11. 20 May, 2014 2 commits
  12. 09 May, 2014 1 commit
    • Tails developers's avatar
      Configure the keyboard model and layout used in the GNOME session, accordingly... · 9f73d4b3
      Tails developers authored
      Configure the keyboard model and layout used in the GNOME session, accordingly to what the user chose in the Greeter.
      
      This depends on Tails Greeter to save the relevant environment variables
      to /var/lib/tails-user-session/keyboard.
      
      Note that we don't set layouts to [chosen one, US] anymore, as I could not make
      it work properly: in this case, regardless of the order in which we set it, the
      US layout wins and is applied by default in the session. Anyway, it's easy
      enough to either directly choose US in the greeter (when one wants the GUI in
      their preferred language, and a US keyboard layout), or to add the US layout in
      the GNOME settings (when using both layouts in the same session). So, this seems
      like an acceptable regression to me.
      9f73d4b3