Thread: [Bashburn-info] Something funky in the config menu
Brought to you by:
bashburn
Menu
▾
▴
bashburn-info
|
From: Anders L. <and...@gm...> - 2008-09-24 21:18:08
|
I noticed some weird behaviour in the config menu. I switched from English to Swedish and applied my changes without exiting the config menu. When choosing an option in the config menu, the description is now in Swedish as it should be. I can exit the config menu, go back to it and the descriptions are in Swedish still. Should I shut down BB, start it again and then enter the config menu, the menu itself is still in Swedish, but the descriptions are now in English. Very strange. I also notice that when the Swedish descriptions do show up, they use colors as they should. For instance when choosing whether to use normalize or not, yes is colored in green and no in red. In the english descriptions colors are never used. Finally, in the advanced menu, no option descriptions are ever printed. -- Anders Lindén http://bashburn.sf.net |
|
From: Steven W. O. <st...@sy...> - 2008-09-25 00:42:47
|
Ok. First of all, the variable bb_menu_adv was not defined for all
languages. This means that Option 6 of the main menu would come up blank
unless it was English or Swedish. I fixed that by using bb_conf_menu_adv
instead.
On Wednesday, Sep 24th 2008 at 17:17 -0000, quoth Anders Lind?n:
=>I noticed some weird behaviour in the config menu.
=>
=>I switched from English to Swedish and applied my changes without
=>exiting the config menu. When choosing an option in the config menu, the
=>description is now in Swedish as it should be. I can exit the config
=>menu, go back to it and the descriptions are in Swedish still.
I traced that back to BashBurn.sh which is doing this:
source_language_modules
. ${BBROOTDIR}/misc/configure_temp_help.lang
We call source_language_modules to set the variables to be in the proper
language and *then* we source in configure_temp_help.lang which overwrites
some of the variables we defined. I just commented it out because if the
default is to provide text in English then I thought we were already doing
that just before calling source_language_modules.
if [[ ! -d ${BBROOTDIR}/lang/${BBLANG} ]]
then
blah...
sleep 3s
# Since the set language did not exist,
# set it to English and save the option
# so that in the future this message is not
# shown again.
BBLANG=English
apply_options
fi
So I'm at a loss to understand what the purpose is of C_T_H.lang and since
it contains duplicate variable defs, it absolutely should be deleted. No?
=>Should I shut down BB, start it again and then enter the config menu,
=>the menu itself is still in Swedish, but the descriptions are now in
=>English. Very strange.
Fixed by commenting out . ${BBROOTDIR}/misc/configure_temp_help.lang
=>I also notice that when the Swedish descriptions do show up, they use
=>colors as they should. For instance when choosing whether to use
=>normalize or not, yes is colored in green and no in red. In the english
=>descriptions colors are never used.
I'll look at that.
=>
=>Finally, in the advanced menu, no option descriptions are ever printed.
AFAIK, the option descriptions never existed. Do you know were they might
have existed in svn history?
--
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steve Orr
Who should we vote for? http://steveo.syslang.net/electionrec-2008/
|
|
From: Steven W. O. <st...@sy...> - 2008-09-25 02:08:04
|
On Wednesday, Sep 24th 2008 at 17:17 -0000, quoth Anders Lind?n: =>I also notice that when the Swedish descriptions do show up, they use =>colors as they should. For instance when choosing whether to use =>normalize or not, yes is colored in green and no in red. In the english =>descriptions colors are never used. Ok. Fixed in 581. The problem was that the lang files were being sucked in *before* the colordefs happened. Therefore the color defs were null at the time that the info messages were defined. It should be better now. What I did *not* see was that it was working for Swedish and not for English. What is more likely is that it worked for neither, but that after you changed language in the same session, then the messages were recreated while the color defs had already been set. And the moral of the story is that what would have prevented this is for package definition to have occurred. Bash doesn't provide for it, but it would have been nice to for, for example, inside lang/English/configure.lang to say require color and inside misc/colors.idx to say provides color Alas :-( -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
|
From: Nick W. <ni...@li...> - 2008-09-25 06:01:18
|
On Wed, 24 Sep 2008 20:42:33 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:
> On Wednesday, Sep 24th 2008 at 17:17 -0000, quoth Anders Lind?n:
>
> =>I noticed some weird behaviour in the config menu.
> =>
> =>I switched from English to Swedish and applied my changes without
> =>exiting the config menu. When choosing an option in the config
> menu, the =>description is now in Swedish as it should be. I can exit
> the config =>menu, go back to it and the descriptions are in Swedish
> still.
>
> Should I shut down BB, start it again and then enter the config menu,
> the menu itself is still in Swedish, but the descriptions are now in
> English. Very strange.
>
>
> I traced that back to BashBurn.sh which is doing this:
>
> source_language_modules
> . ${BBROOTDIR}/misc/configure_temp_help.lang
>
> We call source_language_modules to set the variables to be in the
> proper language and *then* we source in configure_temp_help.lang
> which overwrites some of the variables we defined. I just commented
> it out because if the default is to provide text in English then I
> thought we were already doing that just before calling
> source_language_modules.
>
> if [[ ! -d ${BBROOTDIR}/lang/${BBLANG} ]]
> then
> blah...
> sleep 3s
> # Since the set language did not exist,
> # set it to English and save the option
> # so that in the future this message is not
> # shown again.
> BBLANG=English
> apply_options
> fi
>
> So I'm at a loss to understand what the purpose is of C_T_H.lang and
> since it contains duplicate variable defs, it absolutely should be
> deleted. No?
>
> =>Should I shut down BB, start it again and then enter the config
> menu, =>the menu itself is still in Swedish, but the descriptions are
> now in =>English. Very strange.
>
> Fixed by commenting out . ${BBROOTDIR}/misc/configure_temp_help.lang
OK, this was my fault. The idea is that if the $LANG configure.lang
file has not yet been updated to have the new 'description' variables
(see lang/Italian/configure.lang for an example), then NO help text is
printed at all. So what should happen is these variables get set
instead from configure_temp_help.lang, so at least there is help,
albeit in English.
This is now fixed again correctly. I should have sourced
configure_temp_help.lang FIRST, so that it doesn't clobbered $LANG
configure.lang files that have the correct $VAR
My testing shows this now works as it should. Anders, please attempt
to replicate previous error.
Remember, as the name implies, this is only a temporary hack until all
the configure.lang files are updated. I have commented so in the code.
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Nick W. <ni...@li...> - 2008-09-25 07:08:31
|
On Wed, 24 Sep 2008 23:17:51 +0200 Anders Lindén <and...@gm...> wrote: > Finally, in the advanced menu, no option descriptions are ever > printed. > OK, I have fixed that - this should now work properly. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Anders L. <and...@gm...> - 2008-09-25 12:51:12
|
Nice work guys, I tried the latest revision and it works as it should now. I also committed a tiny correction for BashBurn.sh. Without it the help for the first option in the advanced menu wasn't shown. -- Anders Lindén http://bashburn.sf.net |
|
From: Nick W. <ni...@li...> - 2008-09-25 13:00:12
|
On Thu, 25 Sep 2008 14:50:59 +0200
Anders Lindén <and...@gm...> wrote:
> Nice work guys, I tried the latest revision and it works as it should
> now.
> I also committed a tiny correction for BashBurn.sh. Without it the
> help for the first option in the advanced menu wasn't shown.
I saw that change. Please see my post, I was experimenting with the
advanced menu.
==== copy ====
I have committed a small change. Is this the way to go here?
lang/English/advanced.lang
New $VAR:
bb_adv_cdburncmd_help=\
"This is the command to use to burn a CD.
The current command is ${BBOPTIONCOLOR}${BB_CDBURNCMD}${BBCOLOROFF}"
and in BashBurn.sh
advancedmenu[0]='bb_adv_cdburncmd@BB_CDBURNCMD@bb_adv_cdburncmd_help'
You have to test in English, advanced menu, option 0 ONLY for the
moment.
If it is the way to do it, then all the LANG advanced.lang files will
need changing to.
===========
Nick
--
Free Software Foundation Associate Member 5508
|
|
From: Steven W. O. <st...@sy...> - 2008-09-25 14:56:22
|
On Thursday, Sep 25th 2008 at 02:01 -0000, quoth Nick Warne:
=>On Wed, 24 Sep 2008 20:42:33 -0400 (EDT)
=>> I traced that back to BashBurn.sh which is doing this:
=>>
=>> source_language_modules
=>> . ${BBROOTDIR}/misc/configure_temp_help.lang
=>>
=>> We call source_language_modules to set the variables to be in the
=>> proper language and *then* we source in configure_temp_help.lang
=>> which overwrites some of the variables we defined. I just commented
=>> it out because if the default is to provide text in English then I
=>> thought we were already doing that just before calling
=>> source_language_modules.
=>>
=>> if [[ ! -d ${BBROOTDIR}/lang/${BBLANG} ]]
=>> then
=>> blah...
=>> sleep 3s
=>> # Since the set language did not exist,
=>> # set it to English and save the option
=>> # so that in the future this message is not
=>> # shown again.
=>> BBLANG=English
=>> apply_options
=>> fi
=>>
=>> So I'm at a loss to understand what the purpose is of C_T_H.lang and
=>> since it contains duplicate variable defs, it absolutely should be
=>> deleted. No?
=>>
=>> =>Should I shut down BB, start it again and then enter the config
=>> menu, =>the menu itself is still in Swedish, but the descriptions are
=>> now in =>English. Very strange.
=>>
=>> Fixed by commenting out . ${BBROOTDIR}/misc/configure_temp_help.lang
=>
=>OK, this was my fault. The idea is that if the $LANG configure.lang
=>file has not yet been updated to have the new 'description' variables
=>(see lang/Italian/configure.lang for an example), then NO help text is
=>printed at all. So what should happen is these variables get set
=>instead from configure_temp_help.lang, so at least there is help,
=>albeit in English.
=>
=>This is now fixed again correctly. I should have sourced
=>configure_temp_help.lang FIRST, so that it doesn't clobbered $LANG
=>configure.lang files that have the correct $VAR
=>
=>My testing shows this now works as it should. Anders, please attempt
=>to replicate previous error.
=>
=>Remember, as the name implies, this is only a temporary hack until all
=>the configure.lang files are updated. I have commented so in the code.
Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a stopgap
to provide in case a language is not supported. But if we're in Swahili
and the language is not supported then we should default to English
instead of creating a copy of an English language file. At the most, we
should be looking to see in BBLANG is in the set of supported languages
and if it's not then set it to English. Yes? No?
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
|
|
From: Nick W. <ni...@li...> - 2008-09-25 21:01:13
|
On Thu, 25 Sep 2008 10:56:12 -0400 (EDT) "Steven W. Orr" <st...@sy...> wrote: > Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a > stopgap to provide in case a language is not supported. But if we're > in Swahili and the language is not supported then we should default > to English instead of creating a copy of an English language file. At > the most, we should be looking to see in BBLANG is in the set of > supported languages and if it's not then set it to English. Yes? No? Yes and no. Look at the lang/Italian/configure.lang file (e.g.) It does not HAVE the $VARs associated with the help file, whether it is in Swahili, Klingon, or any other language. If the $VARs do not exist, then nothing gets sourced and no help text when it that language. The rest of the file[s] for menu etc. work OK... so it cannot just be reverted to English as default - just the 'not updated' variables in these files. Nick -- Free Software Foundation Associate Member 5508 |
|
From: Steven W. O. <st...@sy...> - 2008-09-26 15:07:53
|
On Thursday, Sep 25th 2008 at 17:01 -0000, quoth Nick Warne: =>On Thu, 25 Sep 2008 10:56:12 -0400 (EDT) =>"Steven W. Orr" <st...@sy...> wrote: => =>> Nick, Maybe I'm not getting it. I sense that CTH.lang is used as a =>> stopgap to provide in case a language is not supported. But if we're =>> in Swahili and the language is not supported then we should default =>> to English instead of creating a copy of an English language file. At =>> the most, we should be looking to see in BBLANG is in the set of =>> supported languages and if it's not then set it to English. Yes? No? => =>Yes and no. Look at the lang/Italian/configure.lang file (e.g.) => =>It does not HAVE the $VARs associated with the help file, whether it is =>in Swahili, Klingon, or any other language. If the $VARs do not exist, =>then nothing gets sourced and no help text when it that language. => =>The rest of the file[s] for menu etc. work OK... so it cannot just be =>reverted to English as default - just the 'not updated' variables in =>these files. Sorry, not clear yet. Proposal: I will change bb so that when BBLANG gets set, it will only be allowed to be set to an approved value. If the value that the user tries to set it to or if the value in the .bashburnrc is not a supported value then it will be set to English as the default value. Does that work? This implies that if we have a directory for a language, then we must have all variables defined. So, if a new language is created then the proper way to do it is to copy the English directory and then make changes until none of the content is left as English. And to followup, do we have undefined variables in any of the lang subdirs? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net |
Thanks for helping keep SourceForge clean.
X