Re: UI change of "Languge" selection in gdm2



On Mon, Nov 10, 2003 at 03:34:20PM -0800, Chookij Vanatham wrote:
> So right now, first thing I'm really focusing on is delivering
> "a sane language-on-the-fly" PATCH in the following ways.
> 
>   1) MINIMAL change to gdm's user interface
>      There is NO NEED to seperate langauge option between greeter
>      and users's session.
>   2) NO NEED for persistent-greeter-language change
>   3) Some text from the slave (including pam) will need to be
>      in the same/new langauge users select.
>      (I already did this by having "slave process" change its locale
>      to the new one: setlocale (LC_ALL, <new language>): then, some
>      message: ex: "Password" will be displayed in new language).
>   4) Text that goes to the syslog needs to be in system language
>      which is the language when system boots up.
>      (I'll figure this out)

I think 3-4 should be done slightly differently.  Instead of just setlocale
for the whole slave, remember the language in the slave and only do setlocale
to the users language when we're about to say something to the user.  Would
be perhaps useful to have a 'language stack', so that you can do something
like (in the slave)

gdm_push_user_language ()
... some code here ...
gdm_pop_language ()

Say put this around the pam calls.  Those calls could however call some
methods that require the system language, thus it would have to be a stack.

Perhaps this is not required, perhaps just setting and unsetting the system
langauge around all gdm_info/error would be enough.

Also you have to make sure to set back to the system language when the login
failed or the greeter is reset from the slave (do this in the slave).

> Please help me clearify the right behavior when users select option "Last"
> langauge. What langauge we should have "greeter" to be restarted on the fly ?

I think restarting the greeter on the fly after the user enters their login
name would be incredibly annoying.  If this is not possible to do without
restarting greeter (and it is not with the graphical greeter at least since
geometry is managed very insanely there), then we shouldn't switch the
language.  IMO at least.  Loading the greeter can be somewhat expensive,
especially over the network.  On the other hand we could on the fly switch
tha language in the slave, that way at least the slave messages (the actual
questions the user answers) can come in translated.  Note that you need to
make sure to get encodings right.  The greeter is all utf8 no matter what the
encoding is and the slave is the encoding of the locale.  If the language of
the slave will be different from the language of the greeter, the slave must
somehow also give the greeter the locale it's working in.  If I remember
correctly communication is done in system locale whatever that is and it's up
to the greeter to make it utf8 (but I could be wrong, I'm not looking at the
code right now)

> Currently, gdm is able to provide list of various charsets
> for one particular language by adding the message (Charset name)
> after the langauge name (please see snapshots: gdm_various_charsets.rs.gz
> for Chinese langauge as an example) but I have got the request that users
> don't like long list of the same langauge in many choices.

It is up to the administrator to setup the language alias file with only
those that make sense.  I think in the future we're really moving to all utf8
and languages with more then one possibility of charset will become more and
more of a rarity so IMO this is not as useful.

Not to mention that as a user I should be presented with a language, not the
charset.  A regular user will have no clue what a charset is.  If you need to
regularly use more then one charset something is very broken.

George

-- 
George <jirka 5z com>
   Then, when you have found the shrubbery, you must cut down the mightiest
   tree in the forest... with... a herring!
                       -- The Knights Who Say 'Ni'



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]