bashburn-info — BashBurn mailing list

Re: [Bashburn-info] All tabs are now removed from configure and advanced.lang's

[Markus K. <mar...@on...>]

Steven W. Orr wrote:
> Markus, I hope this is ok.
>
>   
--> Steven, it is ok and great idea, that you now have removed all 
cosmetic tabs from all language files.

--> I have added "bb_main_menu=MAIN" to file "BashBurn.lang" in all 
language files like you want it, or Steven?
An exception is the SWEDISH translation:
Anders (or Steven), what coding system did you use in your editor to 
encode/decode this files? My emacs gave me a message while I wanted to 
save the swedish file, that the correct encoding system has to select in 
order to save the file savely. Did you use utf8? Maybe we should make 
also guidlines which coding system to use?

--> Steven please note (info manual of "gettext (libintl library, 
version 0.16.1)"):
"GNU `bash' 2.0 or newer has a special shorthand for translating a
string and substituting variable values in it: `$"msgid"'.  But the use
of this construct is *discouraged*, due to the security holes it opens
and due to its portability problems."

To localize a sentence like
  echo -e "Hello\tworld!"
we can use
 echo -e "`gettext \"Hello\\tworld\"`"

--> By the way I still have the problem that I got no german translation 
in the sub-menues of configuration. Is this only local problem to me?


(Oh... time to go to bed... ;-)  )

Markus

[Bashburn-info] All tabs are now removed from configure and advanced.lang's

[Steven W. O. <st...@sy...>]

Markus, I hope this is ok.

-- 
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

Re: [Bashburn-info] SVN is broken?

[Steven W. O. <st...@sy...>]

On Friday, Sep 12th 2008 at 16:30 -0000, quoth Steven W. Orr:

=>I have changes I made and svn failed to accept them.
=>
=>838 > svn ci
=>svn: Commit failed (details follow):
=>svn: PROPFIND request failed on '/svn/bashburn/lang'
=>svn: '/svn/bashburn/lang' path not found
=>svn: Your commit message was left in a temporary file:
=>svn:    '/home/steveo/bb/bashburn/svn-commit.2.tmp'
=>839 >
=>
=>Anders, is this related to the branch change? Do I need to do something?
=>
=>The three files I modified are
=>
=>M      lang/English/advanced.lang
=>M      lang/English/configure.lang
=>M      menus/bbmenu.sh
=>

OK, I figured it out and the changes I made are in the 3.0 branch.

I need to explain what I did. Cosmetically, it's very small, but it will 
have a ripple on how we do the localization. Markus, please note that I 
modified a couple of the English lang files.

We have a number of entries in the lang files that end in some arbitrary 
number of tabs. e.g., 

bb_adv_cdburncmd="CD Brenn-Befehl\t\t\t"

These tabs have no business being in language files. So what I did was to 
restructure the menu code so that the amopunt of whitespace that comes out 
is a function of the size of the strings that we print. As it sits now, 
all of the languages (besides English) need to have their tabs removed.

As a side effect, we will not be constrained by a) how people have set 
their tabs in the terminal emulator, and b) whether we actually want to 
consume columns in units of whole tabs.

Make sense?

-- 
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

Re: [Bashburn-info] BashBurn branches

[Markus K. <mar...@on...>]

Anders Lindén wrote:
> fre 2008-09-12 klockan 15:09 +0100 skrev Nick Warne:
>   
>> On Fri, 12 Sep 2008 01:28:31 +0200
>> Anders Lindén <and...@gm...> wrote:
>>
>>     
>>> Ok, I created branches on the svn repo. The branch trunk is where
>>> anything goes. Things are allowed to break there.
>>>
>>> In the releases directory we will create a branch when it's time to
>>> stabilize for a release. I added a 3.0 directory there now which is
>>> where we will just make sure things work. No new features are allowed
>>> to be added in releases, only bugfixes.
>>>
>>> So, the gettextification will take place in trunk, and just
>>> stabilization and bug fixing in releases/3.0. When we think things are
>>> stable enough, I'll create a release from the release/3.0 branch and
>>> post it to the webpage.
>>>
>>> Oh, and if I messed something up let me know. I'm no master of svn.
>>>       
>> Good stuff - all appears to work fine.
>>
>> Anders, I guess you are the one that decides what goes into the releases
>> tree[s], and the rest of us just use the trunk?
>>
>> Nick
>>     
>
> I think that when we all think it's time for a release I'll create a
> branch with that name. What goes in there is up to all of us but I
> suggest that only bugfixes and things like translation updates are
> allowed in there. Nothing new should go in there unless you can give a
> really good reason why it should.
> Sounds good to you guys?
>
>   
Sounds good, Anders.
;-)

[Bashburn-info] SVN is broken?

[Steven W. O. <st...@sy...>]

I have changes I made and svn failed to accept them.

838 > svn ci
svn: Commit failed (details follow):
svn: PROPFIND request failed on '/svn/bashburn/lang'
svn: '/svn/bashburn/lang' path not found
svn: Your commit message was left in a temporary file:
svn:    '/home/steveo/bb/bashburn/svn-commit.2.tmp'
839 >

Anders, is this related to the branch change? Do I need to do something?

The three files I modified are

M      lang/English/advanced.lang
M      lang/English/configure.lang
M      menus/bbmenu.sh




-- 
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

Re: [Bashburn-info] BashBurn branches

[Steven W. O. <st...@sy...>]

On Friday, Sep 12th 2008 at 10:34 -0000, quoth Anders Lind?n:

=>fre 2008-09-12 klockan 15:09 +0100 skrev Nick Warne:
=>> On Fri, 12 Sep 2008 01:28:31 +0200
=>> Anders Lind?n <and...@gm...> wrote:
=>> 
=>> > Ok, I created branches on the svn repo. The branch trunk is where
=>> > anything goes. Things are allowed to break there.
=>> > 
=>> > In the releases directory we will create a branch when it's time to
=>> > stabilize for a release. I added a 3.0 directory there now which is
=>> > where we will just make sure things work. No new features are allowed
=>> > to be added in releases, only bugfixes.
=>> > 
=>> > So, the gettextification will take place in trunk, and just
=>> > stabilization and bug fixing in releases/3.0. When we think things are
=>> > stable enough, I'll create a release from the release/3.0 branch and
=>> > post it to the webpage.
=>> > 
=>> > Oh, and if I messed something up let me know. I'm no master of svn.
=>> 
=>> Good stuff - all appears to work fine.
=>> 
=>> Anders, I guess you are the one that decides what goes into the releases
=>> tree[s], and the rest of us just use the trunk?
=>> 
=>> Nick
=>
=>I think that when we all think it's time for a release I'll create a
=>branch with that name. What goes in there is up to all of us but I
=>suggest that only bugfixes and things like translation updates are
=>allowed in there. Nothing new should go in there unless you can give a
=>really good reason why it should.
=>Sounds good to you guys?

Sounds good to me. But since I haven't read the book yet, how do I access 
the branch?

-- 
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.5/

Re: [Bashburn-info] BashBurn branches

[Anders L. <and...@gm...>]

fre 2008-09-12 klockan 15:09 +0100 skrev Nick Warne:
> On Fri, 12 Sep 2008 01:28:31 +0200
> Anders Lindén <and...@gm...> wrote:
> 
> > Ok, I created branches on the svn repo. The branch trunk is where
> > anything goes. Things are allowed to break there.
> > 
> > In the releases directory we will create a branch when it's time to
> > stabilize for a release. I added a 3.0 directory there now which is
> > where we will just make sure things work. No new features are allowed
> > to be added in releases, only bugfixes.
> > 
> > So, the gettextification will take place in trunk, and just
> > stabilization and bug fixing in releases/3.0. When we think things are
> > stable enough, I'll create a release from the release/3.0 branch and
> > post it to the webpage.
> > 
> > Oh, and if I messed something up let me know. I'm no master of svn.
> 
> Good stuff - all appears to work fine.
> 
> Anders, I guess you are the one that decides what goes into the releases
> tree[s], and the rest of us just use the trunk?
> 
> Nick

I think that when we all think it's time for a release I'll create a
branch with that name. What goes in there is up to all of us but I
suggest that only bugfixes and things like translation updates are
allowed in there. Nothing new should go in there unless you can give a
really good reason why it should.
Sounds good to you guys?

-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] BashBurn branches

[Nick W. <ni...@uk...>]

On Fri, 12 Sep 2008 01:28:31 +0200
Anders Lindén <and...@gm...> wrote:

> Ok, I created branches on the svn repo. The branch trunk is where
> anything goes. Things are allowed to break there.
> 
> In the releases directory we will create a branch when it's time to
> stabilize for a release. I added a 3.0 directory there now which is
> where we will just make sure things work. No new features are allowed
> to be added in releases, only bugfixes.
> 
> So, the gettextification will take place in trunk, and just
> stabilization and bug fixing in releases/3.0. When we think things are
> stable enough, I'll create a release from the release/3.0 branch and
> post it to the webpage.
> 
> Oh, and if I messed something up let me know. I'm no master of svn.

Good stuff - all appears to work fine.

Anders, I guess you are the one that decides what goes into the releases
tree[s], and the rest of us just use the trunk?

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] To release or not to release. That is the question.

[Steven W. O. <st...@sy...>]

I'm mixed on the subject. On the one hand, my industrial experience says 
that we should offer something stable to the public. OTOH, my Cathedral 
and the Bazaar side is screaming that the proper methodolgy is to 
release often. That way people are encouraged to become part of the 
testing base. Even in the small group that we have here, I see fixes 
happening so fast that it would make a commercial manager cry. ;-)

Maybe one way we can go is to have a very regular release of unstable 
releases. If there's a known bug that's a show-stopper then we pull it. So 
far, a know problem has not persisted for more than a few days, and few of 
them made it unusable.

I was an active participant as a user of fetchmail, which was ESR's 
experiment at learning how to do open-source projects. It was a very 
active experience. Lots of people. Very enjoyable, lots of contributors. 
It was the basis for the Bazaar metaphor.

It's official: I'm now dangerous. I just printed out a copy of the svn 
book and I'll read it in the next day or so.

Creation of a devel branch is certainly a good idea. Part of the devel 
branch means that the web page needs to be updated with the appropriate 
command to access it. I'd also recommend sending an entry to freshmeat.net 
to advertise.

Re: i18n

I'm good with how Markus sees the progression. 3.1 will be coming very 
quickly. I can see it done in a couple of weeks.

One thing we can do to get started (Markus) is to change all of the .lang 
files (from what I did earlier) so that instead of strings that are single 
quoted. z.b.

bb_fer_gods_sake='Um Gottes Willen'
so we can start the internationalization process by flipping to 
bb_fer_gods_sake=$"Um Gottes Willen"

This is needed to be able to run bash --dump-po-strings from the Makefile.

Also, when that happens, keep an eye out for things that really should 
have been one thing that were broken apart.

e.g.,

bb_text_5='The directory'
bb_text_6='does not exist, although you wrote it into the configfile'
might become
#bb_text_5=$"The directory %s does not exist, \
although you wrote it into the configfile"

One question I have is, do we know how many users we have? Is there a 
record of downloads? Should we add a "Hello to developers" inside a menu 
or give them a script to send us a postcard?

-- 
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

[Bashburn-info] BashBurn branches

[Anders L. <and...@gm...>]

Ok, I created branches on the svn repo. The branch trunk is where
anything goes. Things are allowed to break there.

In the releases directory we will create a branch when it's time to
stabilize for a release. I added a 3.0 directory there now which is
where we will just make sure things work. No new features are allowed to
be added in releases, only bugfixes.

So, the gettextification will take place in trunk, and just
stabilization and bug fixing in releases/3.0. When we think things are
stable enough, I'll create a release from the release/3.0 branch and
post it to the webpage.

Oh, and if I messed something up let me know. I'm no master of svn.
-- 
Anders Lindén
http://bashburn.sf.net

Re: [Bashburn-info] Gettext support

[Markus K. <mar...@on...>]

Anders Lindén wrote:
> tor 2008-09-11 klockan 10:11 -0400 skrev Steven W. Orr:
>   
>> On Thursday, Sep 11th 2008 at 03:11 -0000, quoth Nick Warne:
>>
>> =>On Wed, 10 Sep 2008 22:30:05 -0400 (EDT)
>> =>"Steven W. Orr" <st...@sy...> wrote:
>> =>
>> =>> >From bash however, we are given an extra obstacle. There are two
>> =>> >printf's. 
>> =>> One is the builtin inside bash:
>> =>> 
>> =>> 1519 > printf 'number1 is %2$s, and number2 is %1$s.\n' number2,
>> =>> number1 bash: printf: `$': invalid format character
>> =>> number1 is 1520 >
>> =>> 
>> =>> The other is the binary that's seperate from the builtin:
>> =>> 
>> =>> 1520 > /usr/bin/printf 'number1 is %2$s, and number2 is %1$s.\n' \
>> =>> 		number2  number1
>> =>> number1 is /usr/bin/printf: %$: invalid directive
>> =>> 1521 >
>> =>> 
>> =>> So we can see that they both don't work. Don't let that bother you.
>> =>> Just pretend that the functionality is really there. Worst case I can
>> =>> write a printf that does what we want. z.b., 
>> =>> 
>> =>> awk 'BEGIN {printf "number1 is %2$s, and number2 is %1$s.\n",
>> =>> "number2", "number1"}'
>> =>> number1 is number1, and number2 is
>> =>> number2.
>> =>> 
>> =>
>> =>I just found this:
>> =>
>> =>http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/localization.html
>> =>
>> =>I don't know if it helps here.
>>
>> Nick, you're so modest! This is officially sexy. :-)
>>
>>     
>  I agree. This is awesome. 
>
> A question for you guys. Do you think we should release 3.0 before or
> after we have gettextified BashBurn? I'm thinking that this translation
> might take a while and so it will be quite some time before a new
> version is released. 
> On the other hand we want 3.0 to be as good as it can get, and this new
> translation system would make our baby kick ass.
>
> So what do you think? Stabilize what we have now and wait with the new
> translation system for 3.1, or wait with a release until the translation
> system is in place and then release 3.0? 
>
> I'm leaning towards waiting but I'd like to hear your opinions as well.
>
>   
Yes Nick, this is better then every "hello_world" or "Hallo_Welt" script 
I could make (because even the gettext maintainer  gives his comments).  ;-)

This is a good question Anders.
I personally think (like Nick), we should improve bashburn with the old 
translation system to get a working system.
There are many things that have to be done - even after the great work 
that already has been done.
Then like Nick said, we need time to test and fix errors. After that we 
could release "bashburn 3.0".

And version 3.1 or so could be the one with gettext (since we and the 
translators first must be familiar with the gettext system).

gettext short summary:
Yes the gettext system for bash has mainly 3 steps.

The existing SOURCE_FILE (bashburn) is source for:

1. SOURCE.POT (bashburn)
2. SOURCE.PO (german), SOURCE.PO (lang_xy), ...
3. SOURCE.MO (german), SOURCE.MO (lang_xy), ...

I' m currently working on a simple makefile/infrastructure where we can 
generate this files automatically (e.g. by calling "make mo")  for a 
little gettext translation system.
But I think it is not usefull to check it into the current bashburn 
branch in. Is this the moment we should create a new branch or so, for 
the bashburn version 3.1?
So one part can work on the current version 3.0, and parallel we have 
the future version 3.1 with gettext support.


Markus

Re: [Bashburn-info] Gettext support

[Nick W. <ni...@uk...>]

On Thu, 11 Sep 2008 22:40:37 +0200
Anders Lindén <and...@gm...> wrote:


> A question for you guys. Do you think we should release 3.0 before or
> after we have gettextified BashBurn? I'm thinking that this
> translation might take a while and so it will be quite some time
> before a new version is released. 
> On the other hand we want 3.0 to be as good as it can get, and this
> new translation system would make our baby kick ass.
> 
> So what do you think? Stabilize what we have now and wait with the new
> translation system for 3.1, or wait with a release until the
> translation system is in place and then release 3.0? 
> 
> I'm leaning towards waiting but I'd like to hear your opinions as
> well.

I concur - a good functional release of the new code FIRST.  Then let
it bed in a bit to ensure no issues.

Then take the time to get the gettext stuff done. 

BUT, we still need to test, test, test and test what we have here.  I
can't reiterate enough, nobody seems to test if BB still works?

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Gettext support

[Anders L. <and...@gm...>]

tor 2008-09-11 klockan 10:11 -0400 skrev Steven W. Orr:
> On Thursday, Sep 11th 2008 at 03:11 -0000, quoth Nick Warne:
> 
> =>On Wed, 10 Sep 2008 22:30:05 -0400 (EDT)
> =>"Steven W. Orr" <st...@sy...> wrote:
> =>
> =>> >From bash however, we are given an extra obstacle. There are two
> =>> >printf's. 
> =>> One is the builtin inside bash:
> =>> 
> =>> 1519 > printf 'number1 is %2$s, and number2 is %1$s.\n' number2,
> =>> number1 bash: printf: `$': invalid format character
> =>> number1 is 1520 >
> =>> 
> =>> The other is the binary that's seperate from the builtin:
> =>> 
> =>> 1520 > /usr/bin/printf 'number1 is %2$s, and number2 is %1$s.\n' \
> =>> 		number2  number1
> =>> number1 is /usr/bin/printf: %$: invalid directive
> =>> 1521 >
> =>> 
> =>> So we can see that they both don't work. Don't let that bother you.
> =>> Just pretend that the functionality is really there. Worst case I can
> =>> write a printf that does what we want. z.b., 
> =>> 
> =>> awk 'BEGIN {printf "number1 is %2$s, and number2 is %1$s.\n",
> =>> "number2", "number1"}'
> =>> number1 is number1, and number2 is
> =>> number2.
> =>> 
> =>
> =>I just found this:
> =>
> =>http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/localization.html
> =>
> =>I don't know if it helps here.
> 
> Nick, you're so modest! This is officially sexy. :-)
> 
 I agree. This is awesome. 

A question for you guys. Do you think we should release 3.0 before or
after we have gettextified BashBurn? I'm thinking that this translation
might take a while and so it will be quite some time before a new
version is released. 
On the other hand we want 3.0 to be as good as it can get, and this new
translation system would make our baby kick ass.

So what do you think? Stabilize what we have now and wait with the new
translation system for 3.1, or wait with a release until the translation
system is in place and then release 3.0? 

I'm leaning towards waiting but I'd like to hear your opinions as well.

-- 
Anders Lindén
http://bashburn.sf.net

[Bashburn-info] More on localization

[Steven W. O. <st...@sy...>]

Someone just sent me this comment:


Using gettext also opens up your developers / translators to use
powerful tools like KBabel to maintain translations (the po files) for
your software.

http://kbabel.kde.org/features.php

It looks like a cool tool.

-- 
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

Re: [Bashburn-info] Nick, you've been very patient, but it's now fixed.

[Steven W. O. <st...@sy...>]

On Thursday, Sep 11th 2008 at 07:24 -0000, quoth Nick Warne:

=>On Wed, 10 Sep 2008 21:22:25 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> Cuurently at 530.
=>> 
=>> Recap: Go to advanced config, change two things, revert, then go back
=>> to the main menu. The first item "Audio" would be changed to the
=>> first of the VAR:VAL that you had reverted from in the Advanced menu.
=>> 
=>> Turns out that I had forgotten to declare something as local in 
=>> change_option and so I was overriding the value of a global variable 
=>> somewhere else. Did I mention that declaring things locally is
=>> important? ;-)
=>
=>OK, the advanced menu still doesn't work right.
=>
=>Cahnge two options, revert - the ()* still remains.  Also after a
=>revert, you still get the y/n 'have you saved' dialogue, even though
=>nothing has changed. 
=>
=>Patient isn't an issue - I like debugging and it all helps to make a
=>perfect product :-)  Plus I have been decorating this week, so haven't
=>had much time as I like on the 'puter to try to fix these issues
=>myself :-))

Fixed in 531. Typo. Sorry. 

Re: [Bashburn-info] Gettext support

[Steven W. O. <st...@sy...>]

On Thursday, Sep 11th 2008 at 03:11 -0000, quoth Nick Warne:

=>On Wed, 10 Sep 2008 22:30:05 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> >From bash however, we are given an extra obstacle. There are two
=>> >printf's. 
=>> One is the builtin inside bash:
=>> 
=>> 1519 > printf 'number1 is %2$s, and number2 is %1$s.\n' number2,
=>> number1 bash: printf: `$': invalid format character
=>> number1 is 1520 >
=>> 
=>> The other is the binary that's seperate from the builtin:
=>> 
=>> 1520 > /usr/bin/printf 'number1 is %2$s, and number2 is %1$s.\n' \
=>> 		number2  number1
=>> number1 is /usr/bin/printf: %$: invalid directive
=>> 1521 >
=>> 
=>> So we can see that they both don't work. Don't let that bother you.
=>> Just pretend that the functionality is really there. Worst case I can
=>> write a printf that does what we want. z.b., 
=>> 
=>> awk 'BEGIN {printf "number1 is %2$s, and number2 is %1$s.\n",
=>> "number2", "number1"}'
=>> number1 is number1, and number2 is
=>> number2.
=>> 
=>
=>I just found this:
=>
=>http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/localization.html
=>
=>I don't know if it helps here.

Nick, you're so modest! This is officially sexy. :-)

-- 
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

Re: [Bashburn-info] Nick, you've been very patient, but it's now fixed.

[Nick W. <ni...@uk...>]

On Wed, 10 Sep 2008 21:22:25 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> Cuurently at 530.
> 
> Recap: Go to advanced config, change two things, revert, then go back
> to the main menu. The first item "Audio" would be changed to the
> first of the VAR:VAL that you had reverted from in the Advanced menu.
> 
> Turns out that I had forgotten to declare something as local in 
> change_option and so I was overriding the value of a global variable 
> somewhere else. Did I mention that declaring things locally is
> important? ;-)

OK, the advanced menu still doesn't work right.

Cahnge two options, revert - the ()* still remains.  Also after a
revert, you still get the y/n 'have you saved' dialogue, even though
nothing has changed. 

Patient isn't an issue - I like debugging and it all helps to make a
perfect product :-)  Plus I have been decorating this week, so haven't
had much time as I like on the 'puter to try to fix these issues
myself :-))

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Gettext support

[Nick W. <ni...@uk...>]

On Wed, 10 Sep 2008 22:30:05 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> >From bash however, we are given an extra obstacle. There are two
> >printf's. 
> One is the builtin inside bash:
> 
> 1519 > printf 'number1 is %2$s, and number2 is %1$s.\n' number2,
> number1 bash: printf: `$': invalid format character
> number1 is 1520 >
> 
> The other is the binary that's seperate from the builtin:
> 
> 1520 > /usr/bin/printf 'number1 is %2$s, and number2 is %1$s.\n' \
> 		number2  number1
> number1 is /usr/bin/printf: %$: invalid directive
> 1521 >
> 
> So we can see that they both don't work. Don't let that bother you.
> Just pretend that the functionality is really there. Worst case I can
> write a printf that does what we want. z.b., 
> 
> awk 'BEGIN {printf "number1 is %2$s, and number2 is %1$s.\n",
> "number2", "number1"}'
> number1 is number1, and number2 is
> number2.
> 

I just found this:

http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/localization.html

I don't know if it helps here.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Gettext support

[Steven W. O. <st...@sy...>]

On Wednesday, Sep 10th 2008 at 21:51 -0000, quoth Markus Kollmar:

=>Steven W. Orr wrote:
=>> On Wednesday, Sep 10th 2008 at 15:39 -0000, quoth Markus Kollmar:
=>> 
=>> =>Hm, I have just began some weeks before to check/playing and learning to
=>> =>do gettext for bashburn.
=>> =>I stoped the work, because I thought it is a great thing,  but one must
=>> =>have support for gettext in the lib's of the system.
=>> =>And I was not shure whether it would be worth for us to do - I thought
=>> =>at first the priority to improve bashburn functionality would be more
=>> =>interesting for the most.
=>> =>
=>> =>But I see now the discussion here, which is interesting. What do the
=>> =>others think? Should we rely that a bashburn user has/need i18n
=>> =>(internationalization) support?
=>> =>
=>> =>If the most agree to use gettext, i can start working and experimenting
=>> =>and to find out a strategy we can best implement gettext in bashburn, if
=>> =>it is wished.
=>> 
=>> I took a look at how this might look.
=>> 
=>> A po file is a single language mapping file.  So you need multiple po files,
=>> one file per language.  Then using gettext() you can translate from English
=>> to whatever foreign language you want based on the setlocale() language
=>> setting. (This means that BBLANG would just go away.)
=>> 
=>> Note that the po files are generated from (I think) the pot files. IOW, the
=>> pot files are src code and the po files are the result of a Makefile.
=>> 
=>> So in your bashcode you might have something like:
=>> 
=>>   printf $(gettext "Hello, %s, you have %d messages waiting.\n" \
=>> 	name msgs)
=>> 
=>> and then your po file would contain the mapping of this string to the
=>> language specific translations.  For example es.po would contain:
=>> 
=>> #: ../src/foo.c:244
=>> msgid "Hello, %s, you have %d messages waiting.\n"
=>> msgstr "Hola %s, usted tiene esperar de %d mensajes.\n"
=>> 
=>> Your question about lib support is a non-issue. Literally every system has
=>> all of the support needed. The part that I'm not yet comfortable with is the
=>> idea of whether this is of value in a shell script since these utilities
=>> were designed originally for C code. My feeling is that this is not a
=>> problem, but since I've never been wrong before, it's bound to happen
=>> sometime. ;-)
=>> 
=>> Markus, since you've actually looked at this before, can you take a stab at
=>> implementing a HelloWorld.sh?
=>> 
=>>   
=>Ok, I will try.
=>Please wait.
=>
=>Markus
=>

:-)

I have a few extra notes to add:

po files are a part of the gettext solution for handling 
internationalization (i18n).

They can work quite well. Here's a thumbnail overview.

You create  plain text message files with an extension of .po (This is 
different from what I wrote earlier.)

The content of these looks like this:

msgid "base language message"
msgstr "This is the base language message"

The idea is that the file contains a list of pairs of msgid and msgstr 
values. Typically there is a brief msgid value, which is what you'd use 
within your code for the message lookup, and a full sentence for the 
msgstr value. Note that using this technique makes it easier to actually 
do translations.

You need one po file per language. The files are typically setup in a 
particular language directory structure. Here's the usual setup:

A locale directory that contains one subdirectory per locale. These are 
usually two letter language codes such as en, fr, de, it, ja, zh, es, 
and so forth. Each locale directory then contains a directory name 
LC_MESSAGES, yes in upper case just like that, and within this directory 
goes your po file.

A po file must be pre-processed into an mo file that is binary data. The 
command to do this is:

msgfmt -o messages.mo messages.po

We also have the problem where position information is language dependent.

In one language you might say
"You have 10 items in your shopping cart worth $50 total"
In another language "Your total of $50 is for item count ten"

More succinctly, my grandfather always used to say "Vut iss here going 
on!" :-)

If we were writing C code, we would take advantage of the fact that printf 
allows for a positional notation using (something like) %1$d

#include <stdio.h>
main()
{
    int number1=44;
    int number2=55;
    printf("number1 is %d, and number2 is %d.\n", number1, number2);
    printf("number1 is %2$d, and number2 is %1$d.\n", number2, number1);
} 

>From bash however, we are given an extra obstacle. There are two printf's. 
One is the builtin inside bash:

1519 > printf 'number1 is %2$s, and number2 is %1$s.\n' number2, number1
bash: printf: `$': invalid format character
number1 is 1520 >

The other is the binary that's seperate from the builtin:

1520 > /usr/bin/printf 'number1 is %2$s, and number2 is %1$s.\n' \
		number2  number1
number1 is /usr/bin/printf: %$: invalid directive
1521 >

So we can see that they both don't work. Don't let that bother you. Just 
pretend that the functionality is really there. Worst case I can write a 
printf that does what we want. z.b., 

awk 'BEGIN {printf "number1 is %2$s, and number2 is %1$s.\n", "number2", 
"number1"}'
number1 is number1, and number2 is number2.

-- 
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

Re: [Bashburn-info] Gettext support

[Markus K. <mar...@on...>]

Steven W. Orr wrote:
> On Wednesday, Sep 10th 2008 at 15:39 -0000, quoth Markus Kollmar:
>
> =>Hm, I have just began some weeks before to check/playing and learning to 
> =>do gettext for bashburn.
> =>I stoped the work, because I thought it is a great thing,  but one must 
> =>have support for gettext in the lib's of the system.
> =>And I was not shure whether it would be worth for us to do - I thought 
> =>at first the priority to improve bashburn functionality would be more 
> =>interesting for the most.
> =>
> =>But I see now the discussion here, which is interesting. What do the 
> =>others think? Should we rely that a bashburn user has/need i18n 
> =>(internationalization) support?
> =>
> =>If the most agree to use gettext, i can start working and experimenting 
> =>and to find out a strategy we can best implement gettext in bashburn, if 
> =>it is wished.
>
> I took a look at how this might look.
>
> A po file is a single language mapping file.  So you need multiple po 
> files, one file per language.  Then using gettext() you can translate from 
> English to whatever foreign language you want based on the setlocale() 
> language setting. (This means that BBLANG would just go away.)
>
> Note that the po files are generated from (I think) the pot files. IOW, 
> the pot files are src code and the po files are the result of a Makefile.
>
> So in your bashcode you might have something like:
>
>   printf $(gettext "Hello, %s, you have %d messages waiting.\n" \
> 	name msgs)
>
> and then your po file would contain the mapping of this string to the
> language specific translations.  For example es.po would contain:
>
> #: ../src/foo.c:244
> msgid "Hello, %s, you have %d messages waiting.\n"
> msgstr "Hola %s, usted tiene esperar de %d mensajes.\n"
>
> Your question about lib support is a non-issue. Literally every system has 
> all of the support needed. The part that I'm not yet comfortable with is 
> the idea of whether this is of value in a shell script since these 
> utilities were designed originally for C code. My feeling is that this is 
> not a problem, but since I've never been wrong before, it's bound to 
> happen sometime. ;-)
>
> Markus, since you've actually looked at this before, can you take a stab 
> at implementing a HelloWorld.sh?
>
>   
Ok, I will try.
Please wait.

Markus

[Bashburn-info] Nick, you've been very patient, but it's now fixed.

[Steven W. O. <st...@sy...>]

Cuurently at 530.

Recap: Go to advanced config, change two things, revert, then go back to 
the main menu. The first item "Audio" would be changed to the first of the 
VAR:VAL that you had reverted from in the Advanced menu.

Turns out that I had forgotten to declare something as local in 
change_option and so I was overriding the value of a global variable 
somewhere else. Did I mention that declaring things locally is important? 
;-)

A couple other notes:

* configfunc/get_yn used to take an arg called nomatch that was never 
referenced. Gonzo.

* I found a few other variables that had not been declared locally and a 
couple that were that were not ref'd. Gonzo.

It's getting prettier and prettierer.

-- 
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

Re: [Bashburn-info] Gettext support

[Steven W. O. <st...@sy...>]

On Wednesday, Sep 10th 2008 at 15:39 -0000, quoth Markus Kollmar:

=>Hm, I have just began some weeks before to check/playing and learning to 
=>do gettext for bashburn.
=>I stoped the work, because I thought it is a great thing,  but one must 
=>have support for gettext in the lib's of the system.
=>And I was not shure whether it would be worth for us to do - I thought 
=>at first the priority to improve bashburn functionality would be more 
=>interesting for the most.
=>
=>But I see now the discussion here, which is interesting. What do the 
=>others think? Should we rely that a bashburn user has/need i18n 
=>(internationalization) support?
=>
=>If the most agree to use gettext, i can start working and experimenting 
=>and to find out a strategy we can best implement gettext in bashburn, if 
=>it is wished.

I took a look at how this might look.

A po file is a single language mapping file.  So you need multiple po 
files, one file per language.  Then using gettext() you can translate from 
English to whatever foreign language you want based on the setlocale() 
language setting. (This means that BBLANG would just go away.)

Note that the po files are generated from (I think) the pot files. IOW, 
the pot files are src code and the po files are the result of a Makefile.

So in your bashcode you might have something like:

  printf $(gettext "Hello, %s, you have %d messages waiting.\n" \
	name msgs)

and then your po file would contain the mapping of this string to the
language specific translations.  For example es.po would contain:

#: ../src/foo.c:244
msgid "Hello, %s, you have %d messages waiting.\n"
msgstr "Hola %s, usted tiene esperar de %d mensajes.\n"

Your question about lib support is a non-issue. Literally every system has 
all of the support needed. The part that I'm not yet comfortable with is 
the idea of whether this is of value in a shell script since these 
utilities were designed originally for C code. My feeling is that this is 
not a problem, but since I've never been wrong before, it's bound to 
happen sometime. ;-)

Markus, since you've actually looked at this before, can you take a stab 
at implementing a HelloWorld.sh?

-- 
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

Re: [Bashburn-info] Problems in menues of config

[Steven W. O. <st...@sy...>]

On Wednesday, Sep 10th 2008 at 15:37 -0000, quoth Nick Warne:

=>On Wed, 10 Sep 2008 13:04:49 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> I'm at 528 and I'm not seeing the problem. :-( 
=>> 
=>> The menu printing garbage problem was something I never specifically 
=>> fixed, but when I went to the new bbmenu, the problem went away.
=>> 
=>> The second problem with BB_CONFIG_MODIFIED not being properly set was 
=>> fixed.
=>> 
=>> Can you check where you're at?
=>
=>529
=>
=>Go to advanced menu, change something, change something else, revert
=>changes, exit back to main menu.
=>
=>Menu item 0 is garbage from left over @rray $VAR

Got it! It reproduces so now I can fix it. BTW, mea culpa. I was changing 
the configure menu and not the adv conf menu.

Re: [Bashburn-info] Problems in menues of config

[Nick W. <ni...@uk...>]

On Wed, 10 Sep 2008 13:04:49 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> I'm at 528 and I'm not seeing the problem. :-( 
> 
> The menu printing garbage problem was something I never specifically 
> fixed, but when I went to the new bbmenu, the problem went away.
> 
> The second problem with BB_CONFIG_MODIFIED not being properly set was 
> fixed.
> 
> Can you check where you're at?

529

Go to advanced menu, change something, change something else, revert
changes, exit back to main menu.

Menu item 0 is garbage from left over @rray $VAR

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Gettext support

[Markus K. <mar...@on...>]

Anders Lindén wrote:
> My reply to Steven was sent only to him. I'm reposting the message here.
>
>   
>> As the changes to bb start to wind down, there are new text strings 
>> creeping in and old ones that might want to change. They should be
>>     
> handled 
>   
>> in less of an ad hoc manner; If I change a string now, I'm afraid
>>     
> it'll 
>   
>> just leave the other languages out of sync.
>>
>> Which brings up a new topic... The way that we're handling the
>>     
> different 
>   
>> language problems right now works but it feels somewhat unwieldy. We
>>     
> have 
>   
>> strings in lang/English/somefile.lang and then we have copies of the
>>     
> file 
>   
>> in lang/!English/somefile.lang . Some of the files are mostly
>>     
> translated. 
>   
>> (Good job BTW.) Some languages are there in good shape, but if a
>>     
> string 
>   
>> changes, I don't see a system for *knowing* that the other languages
>>     
> have 
>   
>> to be followed up. Also, we have a lot of strings that are duplicated,
>>     
> and 
>   
>> changing one instance begs the questions whether followup can be
>>     
> managed.
>   
>> So here's the $64 question: Does anyone here have any experience with 
>> gettext/msgfmt/po files/pot files/ etc? Should we keep going the way
>>     
> we 
>   
>> are? I ask this with no prior experience using pot files.
>>
>>     
>
>
> All experience with po files I have is that I helped translate an
> application to Swedish a bunch of years ago. I have no experience in
> actually adding support for it though.
>
> I agree with you though Steven. The translation system is sort of a
> mess. It works yes but it's kind of awkward to work with (All credit to
> me I suppose). I think it would be a good idea to look into using
> gettext. I'm sure it would make translators lives a lot easier. 
>
>   
Hm, I have just began some weeks before to check/playing and learning to 
do gettext for bashburn.
I stoped the work, because I thought it is a great thing,  but one must 
have support for gettext in the lib's of the system.
And I was not shure whether it would be worth for us to do - I thought 
at first the priority to improve bashburn functionality would be more 
interesting for the most.

But I see now the discussion here, which is interesting. What do the 
others think? Should we rely that a bashburn user has/need i18n 
(internationalization) support?

If the most agree to use gettext, i can start working and experimenting 
and to find out a strategy we can best implement gettext in bashburn, if 
it is wished.

Markus