gnome-language selector is labyrinthine

Bug #434351 reported by André Pirard
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
language-selector (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: language-selector

As of 09.10 Karmic ...

An ample list of installed languages is awkward to determine in gnome-language-selector.
(browsing through a long list, missing, and risking to forget the beginning as you reach the end )

If installed languages were moved to the top (before a separator or to another list), it would both ease to quickly see what is currently installed and to tell that from what has been marked for installation or unmarked for removal.
Otherwise said, the language position in the list would be the current installation status and the mark would be the to-be status (any mark below is an addition request, any mark missing from the top is a removal request).
That would be crystal clear.

Hoping it'll be simple enough to do.

Update: and maybe even more following comment #4?

Tags: maverick
Revision history for this message
Arne Goetje (arnegoetje) wrote :

I agree, it needs to be fixed. Targeted for Lucid+1.

Changed in language-selector (Ubuntu):
status: New → Triaged
importance: Undecided → Low
milestone: none → later
Revision history for this message
André Pirard (a.pirard) wrote : Re: [Bug 434351] Re: gnome-language selector is labyrinthine

On 2010-03-17 17:05, Arne Goetje wrote :
> https://bugs.launchpad.net/bugs/434351
> I agree, it needs to be fixed. Targeted for Lucid+1.
>
Thanks for an incentive to make more useful reports.
  **

Revision history for this message
Per Ångström (autark) wrote :

Judging by the looks of language-selector in Maverick RC, nothing substantial has changed: it is still a mess.

tags: added: maverick
Revision history for this message
André Pirard (a.pirard) wrote :

I just thought that, more easily than I sketched it, one could use the
well-known two-columns installed/available language lists between which
you switch them. The code to do that may be readily available in a lib.

André Pirard (a.pirard)
description: updated
Revision history for this message
Niall Murphy (nmurphy) wrote :

To change the system language I had to rely on a "how to":
 http://www.howtogeek.com/howto/17528/change-the-user-interface-language-in-ubuntu/

The bits I was confused with were:
1. Once I had installed the desired language I expected its color to change from grey to black.
    I also semi expected it to jump up to the top of the list for use as a system language.
2. It was not obvious to me that I had to click on the greyed-out language and drag it up the list.
    Because it was grey I thought it was not available.
    However it was obvious to me that I could rearrange the black colored languages.

Revision history for this message
André Pirard (a.pirard) wrote :

 The reason why I introduced this bug report (that was appreciated) is
that it is not obvious for someone having some 6 or more languages to
install, to check which one is or isn't installed already.
Restating myself, the two-columns scheme where installable languages are
in the left column and the installed ones in the right one would be more
appropriate than one-column to be searched.
Nothing such was done

A second, different table was introduced, with similar inconvenience
(and solution) as the first one.
In fact, it duplicates (and extends) the choices proposed by GDM at
login time. And, with the first implementation of this I saw, the two
methods were conflicting. Plus lack of documentation, the fact that all
those Englishes and Spanishes, are the same, the user thinks that he is
facing complete nonsense.

Moreover, what's going on isn't clear at all until you've done it 10 times :
If "Install / Remove Languages..." has to be done first, it might as
well be first on top of the dialog.
And why not with a 1 - 2 - 3... numbering?
- "Language for menus and windows" would best be "This session's language"
- "Use the same language choices for startup and the login screen" ->
"The language chosen above will be used during login"
When will language B be used when "A and B" is the "order of preference"?

Finally...
With Keyboard input method system"="none", I've got SCIM running and
pesting me and my syslog.

Separating language from other locale is welcome. It would be even more
welcome to specify them in detail to, for example, use the by-language
default but specify the date as yy-mm-dd.

ขอขอบคุณสำหรับบทความของคุณแมทธิ

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for keeping sharing your ideas, André! I comment on some of them
below.

On 2010-12-10 22:38, André Pirard wrote:
> A second, different table was introduced, with similar inconvenience
> (and solution) as the first one. In fact, it duplicates (and extends)
> the choices proposed by GDM at login time. And, with the first
> implementation of this I saw, the two methods were conflicting.

Yes they were and still are conflicting. However, the past few weeks
I've worked on that particular issue, and a solution is about to be
uploaded any day now (bug 553162). It would be great if you could
install the versions of language-selector and gdm that include the
fixes:
https://launchpad.net/~gunnarhj/+archive/locale-test
and check out if you think the conflicts are properly dealt with.

> Plus lack of documentation, the fact that all those Englishes and
> Spanishes, are the same, the user thinks that he is facing complete
> nonsense.

Yes, there are far too many menu items for choosing languages. Ideally
there should be one item per available translation.

> Separating language from other locale is welcome. It would be even
> more welcome to specify them in detail to, for example, use the
> by-language default but specify the date as yy-mm-dd.

That would be quite a different approach compared to selecting locale,
and would need to be done in respective application.

Cheers,

Gunnar

Revision history for this message
André Pirard (a.pirard) wrote :

> It would be great if you could install the versions of
> language-selector and gdm that include the fixes:
> https://launchpad.net/~gunnarhj/+archive/locale-test
> and check out if you think the conflicts are properly dealt with.
I have little time, but I'm very soon going to install Ubuntu for
relatives in at least 4 languages and I can apply your updates and
report anything wrong. It will be 10.04. I'm only installing LTS. I
can't afford visiting every 6 months every installation I made.
Thanks for appreciating my comments. Here's another important language
related issue, if you care:
https://bugs.freedesktop.org/show_bug.cgi?id=32342

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Hi again,

On 2010-12-12 23:42, André Pirard wrote:
>
>> It would be great if you could install the versions of
>> language-selector and gdm that include the fixes:
>> https://launchpad.net/~gunnarhj/+archive/locale-test and check out
>> if you think the conflicts are properly dealt with.
>
> I have little time, but I'm very soon going to install Ubuntu for
> relatives in at least 4 languages and I can apply your updates and
> report anything wrong. It will be 10.04.

Great! 10.04 is fine. Besides the released Natty packages, there are
both Lucid and Maverick versions of the altered gdm and
language-selector packages in my PPA.

> Thanks for appreciating my comments.

You're welcome. Suppose you agree on the suggestion in bug 693337, btw.

> Here's another important language related issue, if you care:
> https://bugs.freedesktop.org/show_bug.cgi?id=32342

Well, I'm not fond of that 'feature' either, but I don't care enough to
get involved in it, at least not at the moment.

Merry Christmas!

/ Gunnar

Revision history for this message
Vlad (vlada-m) wrote :

Agree with Niall's comment #2 above - it took me long time to realize that the greyed out items in the list are not inactive and that it is necessary to drag the items in order to make them active.

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.