On Mon, 2008-11-03 at 23:59 -0700, Evan Layton wrote:
> > The "No default Language support" entry is not return by
> > liborchestrator. It is hardcoded in orchestrator-wrappers.c and its
> > related locale "C/POSIX" is also hardcoded. It's intend to used by GUI
> > only but when it is selected as the default language and locale, string
> > "C/POSIX" is passed to liborchestrator and finally goes
> > into /etc/default/init.
> >
> > ---------------->8-----------------------
> > #define NODEFAULTLANGLABEL "No default language support"
> > ....
> > /*
> > * Add C/Posix to the language list
> > */
> > if (nodefault.lang_name == NULL)
> > nodefault.lang_name = g_strdup(_(NODEFAULTLANGLABEL));
> > if (nodefault.lang == NULL)
> > nodefault.lang = g_strdup(_(NODEFAULTLANGLABEL));
> >
> > ---------------->8-----------------------
> > /* language stuff */
> > static locale_info_t cposix = {
> > N_("C/POSIX"),
> > N_("C/POSIX"),
> > B_FALSE,
> > NULL
> > };
> > ---------------->8-----------------------
> >
> > To fix the problem, I think I can set the locale name (which is passed
> > to liborchestrator) to "C" which is a valid locale. What do you think?
>
> I was thinking that this would probably fix this issue but wanted to talk
> through it with you to make sure I wasn't missing something. Would it also
> make
> sense to use B_TRUE here so that cposix is the default locale for "No default
> Language support"?
It seems the boolean value is provided to GUI to show default locale.
And for GUI, it dose not matter too much because if no default locale is
available, GUI will use the 1st one and there is only one locale for "No
default language support"entry. But I think it's a good practice to let
it B_TRUE. I will update my patch.
>
> >
> > I filed 2 bugs, http://defect.opensolaris.org/bz/show_bug.cgi?id=4499
> > and http://defect.opensolaris.org/bz/show_bug.cgi?id=4500 for the
> > problem.
>
> Do these solve the problems seen in 3254 as well or is there more to it then
> what we've talked about here? It appears from the bug reports that 3254 was
> split into 4499 and 4500 and should be closed when these are fixed. Does that
> sound correct?
Yes, 3524 can be recognized as too bugs: 4499 and 4500.
Regards,
Jedy
>
> >
> > Regards,
> >
> > Jedy
>
> Thank you for looking at this and waling through it for me!
>
> -evan
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
