No shortcut available for "forward" button for Chinese during installation / oem-config

Bug #892386 reported by Kent Baxley
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OEM Priority Project
Won't Fix
Medium
Brian Murray
Oneiric
Won't Fix
Medium
Unassigned
Precise
Won't Fix
Medium
Unassigned
Quantal
Won't Fix
Medium
Unassigned
Raring
Won't Fix
Medium
Brian Murray
Ubuntu Translations
Invalid
Medium
Unassigned
ubiquity (Ubuntu)
Expired
High
Unassigned
Nominated for Raring by James M. Leddy

Bug Description

For installations where Simplified Chinese is the default language, there is no shortcut available for the Forward Button in either the installer or during oem-config. There are shortcuts for Back (B) and Quit (Q). Chinese users can press Alt+B or Alt+Q to move backward or quit the installation, but, there's nothing that will allow them to press Alt+F to move forward. I have attached a photo as an example of what the user sees.

Steps to reproduce:

1) Install Ubuntu 11.10 and select Simplified Chinese as the language.

Actual Results:
During installation (or oem-config) there is no shortcut available for the forward button.

Expected Results:

In addition to being able to quit, cancel, or go backward, the user should also have an (F) on the button and press Alt+F to move forward through the installation.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 3.0.0-13.22somerville1-generic 3.0.6
Uname: Linux 3.0.0-13-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Sat Nov 19 06:31:10 2011
DistributionChannelDescriptor:
 # This is a distribution channel descriptor
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-oneiric-amd64-20111116-1
InstallationMedia: Ubuntu 11.10 "Oneiric" - Build amd64 LIVE Binary 20111116-18:24
ProcEnviron:
 LANGUAGE=zh_CN:zh
 PATH=(custom, no user)
 LANG=zh_CN.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Kent Baxley (kentb) wrote :
Revision history for this message
Kent Baxley (kentb) wrote :

Example photo of the buttons.

Changed in oem-priority:
importance: Undecided → Medium
Kent Baxley (kentb)
Changed in oem-priority:
importance: Medium → High
Revision history for this message
Steve Magoun (smagoun) wrote :

Set oem-priority priority to medium to match other l10n-related priorities

Changed in oem-priority:
importance: High → Medium
Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Evan, this looks necessary for the OEM team, can you please take a look and see if it's addressable?

Changed in ubiquity (Ubuntu):
assignee: nobody → Evan Dandrea (ev)
importance: Undecided → High
tags: added: rls-mgr-p-tracking
Changed in oem-priority:
assignee: nobody → Brian Murray (brian-murray)
Revision history for this message
Stéphane Graber (stgraber) wrote :

Ubiquity usually doesn't have shortcuts in its UI. For some reason whoever translated gtk in Chinese did it for the stock buttons making ubiquity's UI look weird.

The way to fix it is to have someone on the Chinese translation team, update:
继续 for 继续 (_F) so it'll add a ctrl+f shortcut to the button and show it in the UI.

https://translations.launchpad.net/ubuntu/oneiric/+source/ubiquity/+pots/ubiquity-debconf/zh_CN/+translate?batch=10&show=all&search=%E7%BB%A7%E7%BB%AD for Oneiric and https://translations.launchpad.net/ubuntu/precise/+source/ubiquity/+pots/ubiquity-debconf/zh_CN/+translate?batch=10&show=all&search=%E7%BB%A7%E7%BB%AD for Precise

The exact English string is "Continue", I already proposed a new Chinese translation adding the shortcut, just need someone from the Chinese translation team to accept it.

By the way, it'd be great if in the future you include the string as part of the bug report as it took me quite a while to go through Ubiquity's 250 strings looking for the right Chinese characters (well, actually doing some shell to extract all of these that were exactly 2 characters long, then going through them) :)

Changed in ubiquity (Ubuntu):
status: New → Triaged
Changed in oem-priority:
status: New → Triaged
Chris Van Hoof (vanhoof)
Changed in oem-priority:
status: Triaged → In Progress
status: In Progress → Confirmed
David Planella (dpm)
Changed in ubuntu-translations:
assignee: nobody → Ubuntu Simplified Chinese Translators (ubuntu-l10n-zh-cn)
Revision history for this message
YunQiang Su (wzssyqa) wrote :

Maybe the "Continue" should be "_Forward" in source code ?

Revision history for this message
Aron Xu (happyaron) wrote :

Remove the assignment on ubuntu-l10n-zh-cn and suggestions are not approved. We never apply workarounds in translations for shortcuts. And I guess this bug is not zh_CN specified, but is valid for all languages.

As for Back and Quit, I don't think they are caused by bugs in GTK+'s translation, as in the following PO file:
http://l10n.gnome.org/POT/gtk+.gtk-3-2/gtk+.gtk-3-2.zh_CN.po

#. This is a navigation label as in "go back"
#: ../gtk/gtkstock.c:353
msgctxt "Stock label, navigation"
msgid "_Back"
msgstr "后退(_B)"

#: ../gtk/gtkstock.c:413
msgctxt "Stock label"
msgid "_Quit"
msgstr "退出(_Q)"

The msgids have _B and _Q, which are hints for accelerators, so the Chinese translations are correct. If we remove the them from translations then all GTK+ programs will end up with missing accelerators.

Therefore the bug is in ubiquity, which should add corresponding shortcuts so all translation teams will know what they should do to the translations.

Changed in ubuntu-translations:
assignee: Ubuntu Simplified Chinese Translators (ubuntu-l10n-zh-cn) → nobody
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
David Planella (dpm) wrote :

From the conversation on IRC:

- As Aron is mentioning in his comment, this bug affects all languages, not only Simplified Chinese
- It's caused by mixing a stock button (with shortcut) with a non-stock one (without shortcut)
- Someone needs to make a decision on how to best fix it

<dpm> cjwatson, stgraber, the Chinese translators didn't seem to happy about adding a shortcut on the translation where there isn't one in the original string. I've asked them to comment on the bug
<cjwatson> I kind of wonder why we don't have a shortcut on that msgstr to match GTK, in some ways
 maybe it's also used in the KDE frontend though?
<stgraber> dpm: I can definitely understand that, though the reason for the bug is that they added it for all the other ones in gtk ...
 dpm: so they should either add the shortcut for that one too or remove all of these they added for all the gtk stock buttons
 dpm: otherwise you get an inconsistent installer UI
<dpm> stgraber, I'm not sure I quite follow why the shortcut appears in one button and not in the other. Is it because the Back one is stock and thus has a shortcut, and the Continue one is not stock and doesn't have one?
 if so, would it not be better to add a shortcut in the Continue button in the source code?
<cjwatson> stgraber: well, no, the "Continue" string is in ubiquity proper but the others are imported from GTK
<cjwatson> dpm,stgraber: yeah, on inspection, this string is shared with KDE which I'm fairly sure has different shortcut conventions
<cjwatson> so I don't think it can be as simple as adding _, even in the translation
* cjwatson tries to remember why the stock labels weren't good enough
<cjwatson> It would read "Forward" rather than "Continue"
<cjwatson> but it does seem illogical to use stock labels for one thing and not another, in the same button bar
<cjwatson> maybe check with mpt?
<cjwatson> our back/forward button handling doesn't look desperately consistent in general
<mpt> dpm, I don't know why the stock string was never changed. Probably because it was inappropriately shared with (for example) the navigation buttons in browsers, where you do want just "Back" and "Forward"
<dpm> mpt, what do you think the best way to solve that bug and be consistent should be? Both stock buttons with shortcut, or both non-stock buttons?
<mpt> dpm, I think the best way would be to make the keyboard combo for going to the next step Enter, and the keyboard combo for going to the previous step Esc.
<dpm> mpt, cjwatson, that's probably a solution for +1, though, right? ^ Is there anything that can be done at this point in the cycle, or should the bug be wontfix for oneiric and precise?
<cjwatson> mpt: I thought that was in general the case anyway, but it's not very discoverable so people missed it
<mpt> cjwatson, if something isn't discoverable, I try to make it more discoverable before adding a second thing :-)

David Planella (dpm)
Changed in ubuntu-translations:
status: Triaged → Invalid
tags: added: rls-mgr-q-tracking
tags: added: rls-q-incomming
removed: rls-mgr-q-tracking
Colin Watson (cjwatson)
tags: added: rls-q-incoming
removed: rls-q-incomming
Revision history for this message
Steve Langasek (vorlon) wrote :

> <mpt> dpm, I think the best way would be to make the keyboard combo for going to the next step Enter, and the keyboard combo for going to the previous step Esc.
> <dpm> mpt, cjwatson, that's probably a solution for +1, though, right? ^ Is there anything that can be done at this point in the cycle, or should the bug be wontfix for oneiric and precise?
> <cjwatson> mpt: I thought that was in general the case anyway, but it's not very discoverable so people missed it
> <mpt> cjwatson, if something isn't discoverable, I try to make it more discoverable before adding a second thing :-)

So it doesn't seem like there's a consensus here that the shortcuts for the forward button *should* be changed, and therefore we don't have a clear way forward on resolving this bug.

tags: added: rls-q-notfixing
removed: rls-q-incoming
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I've been playing with ubiquity a bit recently, so I decided to check this out. Today, Enter will go to the next screen, by virtue of property has_default=True. Escape does nothing. Alt+B will go back but isn't documented in the English install. Since use_underline=True, I've whipped up a patch which adds an underline, so that Alt+C is continue. I've also taken out use_stock=True which doesn't make sense in this context since "Continue" is not a gtk stock button.

KDE UI files don't have the same default with underline property, and none of the buttons are stock buttons, so I don't think it suffers from this problem.

http://paste.ubuntu.com/1062926/

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Since we have declined this for quantal, I am going to close the oem-priority task on this bug. We would still like it to be fixed in the -r release however.

Changed in oem-priority:
status: Confirmed → Won't Fix
Evan (ev)
Changed in ubiquity (Ubuntu):
assignee: Evan Dandrea (ev) → nobody
Revision history for this message
Marcus Tomlinson (marcustomlinson) wrote :

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

Changed in ubiquity (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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