19.04 installer displays keyboard layouts in the wrong language

Bug #1817453 reported by Diego Germán Gonzalez on 2019-02-24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
console-setup (Ubuntu)
Iain Lane
Iain Lane

Bug Description

When you select the Spanish language in the installer, when you go to the keyboard layout selection these are in another language. The options for Latin American Spanish do not appear.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: ubiquity 19.04.5
ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
Uname: Linux 4.19.0-13-generic x86_64
ApportVersion: 2.20.10-0ubuntu21
Architecture: amd64
CasperVersion: 1.402
CurrentDesktop: ubuntu:GNOME
Date: Sun Feb 24 06:51:45 2019
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd quiet splash --- maybe-ubiquity
LiveMediaBuild: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190223)
 PATH=(custom, no user)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Sebastien Bacher (seb128) wrote :

Thank you for your bug report, your screenshot shows an UI which seems properly translated, what strings do you have an issue with?

Changed in ubiquity (Ubuntu):
importance: Undecided → Low

In the new screenshot, note the square sectors. This is not a Spanish variant that I recognize.
Also, there are no keyboard layout options for Latin America.

Changed in ubiquity (Ubuntu):
importance: Low → High
summary: - Ubiquity is not well translated into Spanish
+ 19.04 displays keyboard layouts in the wrong language
summary: - 19.04 displays keyboard layouts in the wrong language
+ 19.04 installer displays keyboard layouts in the wrong language
tags: added: rls-dd-incoming
Rik Mills (rikmills) wrote :

Similar with German. Attachment shows translations of keyboard layout in something not German (perhaps Hungarian?)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Rik Mills (rikmills) wrote :

In addition, translations of base languages on the left when I try to really find 'Deutsch' seem to be in Dutch? e.g. Duits for Deutsch

In the Daily build 2019-02-26 09:32 the problem is solved for the Spanish language and the Latin American Spanish keyboard configuration.

tags: removed: rls-dd-incoming
Iain Lane (laney) wrote :

laney@raleigh> echo "get keyboard-configuration/variant" | debconf-communicate
debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied
0 английска — великобританска

This is on my *installed* system. That is "English - British" in Bulgarian... It shouldn't be translated like that.

Iain Lane (laney) wrote :

in a fresh disco lxd container:

$ locale-gen en_GB.UTF-8
$ export LC_ALL=en_GB.UTF-8
$ dpkg-reconfigure keyboard-configuration

The options are incorrectly translated.

Iain Lane (laney) wrote :

I think KBDNAMES in keyboard-configuration is mega wrong. e.g.:

en_GB*model*sun_type6_jp*Sun Type 6 (Japanese)

en_GB*model*sun_type6_jp*Sun Type 6 (Japonesa)

Iain Lane (laney) wrote :

This is a stripped down version of kbdnames-maker from console-setup. Install xkb-data-i18n and locales-all before running it.

On disco it switches to returning "Sun Type 6 (Japonesa)" after "ca" for all of the remaining languages.
On cosmic it returns the properly translated strings all the way.

Iain Lane (laney) wrote :

The following additional packages will be installed:
  libgdbm-compat4 libgdbm6 liblocale-gettext-perl libperl5.28 libtext-charwidth-perl perl perl-base perl-modules-5.28
Suggested packages:
  gdbm-l10n perl-doc libterm-readline-gnu-perl | libterm-readline-perl-perl make
The following NEW packages will be installed:
  libgdbm6 libperl5.28 perl-modules-5.28
The following packages will be upgraded:
  libgdbm-compat4 liblocale-gettext-perl libtext-charwidth-perl libtext-iconv-perl perl perl-base

This upgrade (cosmic -> disco perl) broke it.

Iain Lane (laney) wrote :

Think I've fixed this

affects: ubiquity (Ubuntu Disco) → console-setup (Ubuntu Disco)
Changed in console-setup (Ubuntu Disco):
assignee: nobody → Iain Lane (laney)
status: Confirmed → In Progress
tags: added: id-5c8a78260a33937a98c3c550
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package console-setup - 1.178ubuntu11

console-setup (1.178ubuntu11) disco; urgency=medium

  * kbdnames-maker: Call `{bind,}textdomain` after switching locale.
    There's a change in perl 5.28 to use `uselocale()` & friends instead of
    gettext directly, to support thread safety. Apparently this causes the
    results of `gettext()` calls to be cached now where they weren't before,
    and this breaks our keyboard name generation. For example, we have
    `en_GB*model*sun_type6_jp*Sun Type 6 (Japonesa)` instead of
    `en_GB*model*sun_type6_jp*Sun Type 6 (Japanese)`, and many many other
    examples. Calling `bindtextdomain()` and then `textdomain()` after
    changing locale causes the cache to be invalidated and we get correct
    results again. LP: #1817453

 -- Iain Lane <email address hidden> Fri, 15 Mar 2019 12:34:06 +0000

Changed in console-setup (Ubuntu Disco):
status: In Progress → Fix Released
Iain Lane (laney) wrote :

This should be fixed in dailies from today (20190316)

On 15/03/2019 14:53, Launchpad Bug Tracker wrote:
> This bug was fixed in the package console-setup - 1.178ubuntu11

This now causes LP: #1810647 to occur again.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers