"Keyboard Layout Options" misspells Caps Lock as "CapsLock"

Bug #592448 reported by Matthew Paul Thomas on 2010-06-10
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
xkeyboard-config
Fix Released
Medium
xkeyboard-config (Ubuntu)
Low
Unassigned

Bug Description

gnome-control-center 1:2.30.0-0ubuntu4, Ubuntu 10.04

1. Navigate to "System" > "Preferences" > "Keyboard" > "Layouts" > "Options" > "Caps Lock key behavior".

The heading correctly spells it "Caps Lock". But 13 of the 14 options inside misspell it as "CapsLock".

Sebastien Bacher (seb128) wrote :

those options are coming from xkeyboard-config, see the files in /usr/share/X11/xkb/rules

affects: control-center (Ubuntu) → xkeyboard-config (Ubuntu)
Changed in xkeyboard-config (Ubuntu):
importance: Undecided → Low
Gursimran singh (simar) wrote :

Whatever be the reason these config files by default have the spelling mistake that should be taken care of by the developers and also all the information is available to fix the bug. So I'm changing the status to Triaged.

Changed in xkeyboard-config (Ubuntu):
status: New → Confirmed

A user (launchpad) noticed that Caps Lock is sometimes found as 'CapsLock' (that is, without a space in between, in messages.

Is this considered a typo?
As far as I have seen, this is found in base.xml.in.

The en_GB localisation translates CapsLock to Caps Lock.

Actually in all cases in base.xml.in it is written as CapsLock. Where do you see it as Caps Lock?

(In reply to comment #1)
> Actually in all cases in base.xml.in it is written as CapsLock. Where do you
> see it as Caps Lock?

You are right, there is no Caps Lock in rules/*. I mixed it up with po/* where it is translated to Caps Lock.

Well, the translations are managed by TP. I do not have much influence there...

Simos Xenitellis  (simosx) wrote :

I've linked upstream with a bug report,
https://bugs.freedesktop.org/show_bug.cgi?id=28877

Let's here from the developer on this.

(In reply to comment #3)
> Well, the translations are managed by TP. I do not have much influence there...

From the maintainer's side, you may choose to update base.xml.in so that CapsLock becomes Caps Lock.
There is no significant work for the translators side as they just need to unfuzzy a few messages that are already translated correctly.

Created an attachment (id=36679)
Patch for Scroll Lock

Adding for comparison on the extent of the changes.

Created an attachment (id=36680)
Patch for Num Lock

Adding for comparison on the extent of the changes.

Created an attachment (id=36681)
Patch for Caps Lock

Adding for comparison on the extent of the changes.

I actually do not know what is the right way. What would be correct English: CapsLock or Caps Lock?

(In reply to comment #8)
> I actually do not know what is the right way. What would be correct English:
> CapsLock or Caps Lock?

I believe it should be Caps Lock.

All references point to 'Caps Lock'; http://en.wikipedia.org/wiki/Caps_lock
which follow Num Lock and Scroll Lock.

Ghm. I am still hesitant. Can tell you why. There are cases where separating words can cause confusion:

Alt+Caps Lock does the original capslock action

Shift+Caps Lock

That can be read as ("Alt+Caps") Lock and ("Shift+Caps") Lock. Absolute nonsense, but still...

Should "Caps Lock" be but in quotes? I do not know...

(In reply to comment #10)
> Ghm. I am still hesitant. Can tell you why. There are cases where separating
> words can cause confusion:
>
> Alt+Caps Lock does the original capslock action
>
> Shift+Caps Lock
>
> That can be read as ("Alt+Caps") Lock and ("Shift+Caps") Lock. Absolute
> nonsense, but still...
>
> Should "Caps Lock" be but in quotes? I do not know...

The issue is that 'CapsLock/Caps Lock' is used both in free text and as part of notation (as in Alt+CapsLock).
Since we cannot use text formatting to make the distinction (probably GNOME UI guidelines?), we could use 'CapsLock' for the notation, and Caps Lock in the free text (elsewhere).

> The issue is that 'CapsLock/Caps Lock' is used both in free text and as part of
> notation (as in Alt+CapsLock).
Yes.

> Since we cannot use text formatting to make the distinction (probably GNOME UI
> guidelines?),
What kind of formatting would you use? We cannot make assumptions about the way GUI tools are going to use the xml.

> we could use 'CapsLock' for the notation, and Caps Lock in the
> free text (elsewhere).
Ghm... This is kind of inconsistent... I've always thought about CapsLock in context of "notation" (as you call it), that's why I did not use space. Will review the strings again..

The normal convention in English is that new ideas start as multiple
words, possibly combined with hyphens, and over time become a single
word. CapsLock has been around long enough to be a word of its own.

As have ShiftLock, et al.

All that said, however, the symbols have _-separation; it also would
be reasonable, therefore, to use Caps_Lock, et al everywhere.

(In reply to comment #13)
> The normal convention in English is that new ideas start as multiple
> words, possibly combined with hyphens, and over time become a single
> word. CapsLock has been around long enough to be a word of its own.
>
> As have ShiftLock, et al.
>
> All that said, however, the symbols have _-separation; it also would
> be reasonable, therefore, to use Caps_Lock, et al everywhere.

Just to continue the bikeshedding, I think it looks horrendously ugly and over-technical, and this is borne out by most keyboards I see separating it with a space (including the one I'm typing this on).

I agree - using underscore makes it look too technical, if not geeky.
It is a pity bugzilla does not allow voting:)

On Mon, Jul 05, 2010 at 12:00:12PM -0700, <email address hidden> wrote:
> I agree - using underscore makes it look too technical, if not geeky.
> It is a pity bugzilla does not allow voting:)

Bear in mind I think the same about CapsLock, not just Caps_Lock. :)

> Bear in mind I think the same about CapsLock, not just Caps_Lock. :)

How would you write this:

Alt+Caps Lock does the original capslock action

?

On Mon, Jul 05, 2010 at 12:07:58PM -0700, <email address hidden> wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=28877
>
> --- Comment #17 from Sergey V. Udaltsov <email address hidden> 2010-07-05 12:07:58 PDT ---
> > Bear in mind I think the same about CapsLock, not just Caps_Lock. :)
>
> How would you write this:
>
> Alt+Caps Lock does the original capslock action

Maybe as 'Alt + Caps Lock', instead of Alt+CapsLock? If you really want
to make sure, maybe <em>Alt</em> + <em>Caps Lock</em> ...

Created an attachment (id=36772)
Screenshot showing most messages relating to CapsLock text.

I attach a screenshot that shows most of the messages that have the CapsLock text. It shows about 60-70% of the messages having to do with the three patches attached.

The purpose of this bug report is to figure out how to do usability enhancements that is normally associated to distributions. Due to the nature of xkeyboard-config and since the 'consumer' of xkeyboard-config is principally GNOME, we do that usability enhancement exercise on the messages here.

If we were to take it further, we would show graphically that these 'Alt', 'Caps Lock' are actually keyboard keys. There is a Unicode character for keycap, like a⃣ but it does not look like it works for multiple characters.

Doing CapsLock->Caps Lock would be a gradual improvement.

I agree - in that group "Caps Lock" would look more natural. So, perhaps we should use "Caps Lock", along with "Alt + 'Caps Lock'" etc

Final call: objections, anyone?

For a moment, committed just with spaces. Will play with quotes...

On Mon, Jul 12, 2010 at 03:53:51PM -0700, <email address hidden> wrote:
> For a moment, committed just with spaces. Will play with quotes...

I still think wrapping modifiers in <em /> in the UI would make the most
sense, especially as it visually differentiates modifiers from normal
keys.

> I still think wrapping modifiers in <em /> in the UI would make the most
> sense, especially as it visually differentiates modifiers from normal
> keys.
I see your point. I am not sure how to implement that in a way that would not depend on features of some particular toolkit - so any tool (including console-based) would be able to use those descriptions.

Changed in xkeyboard-config:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in xkeyboard-config:
importance: Medium → Unknown
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xkeyboard-config - 2.1-1ubuntu1

---------------
xkeyboard-config (2.1-1ubuntu1) natty; urgency=low

  * Merge from debian of 2.1 release.
    - Fixes Ubuntu bugs:
      + Sindhi keyboard layout (locale: sd_PK, sd_IN) (LP: #588918)
      + Fix conflict between Mali and Malayalam layouts (LP: #575660)
      + Support for Philippines "National Keyboard Layout" (LP: #672881)
      + Support for Kinesis keyboard geometry (LP: #393887)
      + Support for Apple Aluminium keyboards (LP: #696232)
      + Support for abnt2 keyboard, thinkpad variant for Lenovo 3000 v100
        laptops (LP: #359719)
      + Fix CapsLock misspelling (LP: #592448)
    - Remaining Ubuntu changes:
      + xkb-data-i18n.install, xkb-data.install, rules: Split out
        xkb-data-i18n to be used by console-setup.
      + rules: Generate pot file for translations during build
      + 104_macbook_expose_and_dashboard.patch: Add keycode definitions
          required for Apples Expose & Dashboard keys (F3/F4).
      + 105_intelligent_keyboard.patch: Add support for the Intelligent
        Keyboard K04
      + 107_lao.patch: New keyboard layout for Lao, implemented as
        an alternative to the default one.
      + 108_taiwan.patch: New keyboard layouts for Taiwan.
  * Drop 102_mac_aliases.patch: This appears to have some side effects,
    and the patch was not taken by upstream because it was an incomplete
    fix. Reopens bug 327963
  * Drop patches included in the new upstream release:
      - 106_fixspell3d.patch: upstream
      - 109_mali.patch: upstream
      - 110_variants-cleanup.patch
      - 111_il-missing-symbol.patch
      - 112_zero-with-spacing.patch
      - 113_cz-dvorak-ucw.patch
      - 114_ejn_4_level.patch
      - 115_aluminium_geometries.patch
      - 116_aluminium_keycodes.patch
      - 117_aluminium_symbols.patch
      - 118_aluminium_aliases.patch
      - 119_aluminium_pc_compat.patch
      - 120_aluminium_rules.patch
      - 121_tamil_chars.patch
      - 122_olpc-azerty.patch
      - 123_fix_i18n.patch
      - 124_serbian_ru_level3.patch
      - 125_mapping_tools_launch5_menukb.patch
      - 126_swahili_arabic.patch
      - 127_restore_gb_colemak.patch
 -- Bryce Harrington <email address hidden> Tue, 01 Feb 2011 11:57:39 -0800

Changed in xkeyboard-config (Ubuntu):
status: Confirmed → Fix Released
Changed in xkeyboard-config:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.