Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 22 May 2013, 13:41
All times are UTC - 4

 Forum index » Off-Topic Area » Programming
Bash internationalisation problem (Solved..perhaps)
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [11 Posts]  
Author Message
01micko


Joined: 11 Oct 2008
Posts: 7018
Location: qld
PostPosted: Fri 21 May 2010, 22:00    Post subject:  Bash internationalisation problem (Solved..perhaps)  
Hi

I am using zigbert's model to internationalise a program.

Code:
#set language
[ $LANGUAGE = auto ] && TMP="`ls -1 $APPDIR/locals/ | grep $LANG`"
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[ "$TMP" != "en_US:english" ] && . $APPDIR/locals/$TMP 2> /dev/null


But it throws the "unary operator expected" error in the first line "[ $LANGUAGE = auto ]", so I guess it will always fall back to en_US because of the error. (I have no translations to test) EDIT: of course! zigbert has that in his *rc files.. but is that just chosen arbitrarily?

Some questions...

Where is LANGUAGE defined ? EDIT: I found that.. it's user defined.
Is there a better way? Maybe, maybe not.
Can I skip that $LANGUAGE test? Possibly since I'm not allowing the user to choose.

Any advice gratefully received.

Cheers
_________________
keep the faith Cool ..
Back to top
View user's profile Send private message Visit poster's website 
big_bass


Joined: 13 Aug 2007
Posts: 1736
PostPosted: Sat 22 May 2010, 00:41    Post subject:  
hey micko

original
#set language
[ $LANGUAGE = auto ] && TMP="`ls -1 $APPDIR/locals/ | grep $LANG`"
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[ "$TMP" != "en_US:english" ] && . $APPDIR/locals/$TMP 2> /dev/null


edited
#set language
[ "$LANGUAGE" = auto ] && TMP="`ls -1 $APPDIR/locals/ | grep $LANG`"
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[ "$TMP" != "en_US:english" ] && . $APPDIR/locals/$TMP 2> /dev/null



using double quotes on strings "$LANGUAGE"
takes care of the error
bash: [: =: unary operator expected




-------------------------------------------
Quote:
Where is LANGUAGE defined ? EDIT: I found that.. it's user defined.
Can I skip that $LANGUAGE test?




its easy to modify this one just for the different languages
DEFAULTLANG is always what it is but you could make tests also
for checking errors

Code:

 DEFAULTLANG=(`env |grep "LANG="`)

 if [   $DEFAULTLANG = "LANG=en_US" ]; then
               echo $DEFAULTLANG
     
 
 elif [   $DEFAULTLANG = "LANG=C" ]; then
               echo "you got borked :D"
               
 fi




Joe
_________________
slackware 14
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 7018
Location: qld
PostPosted: Sat 22 May 2010, 03:14    Post subject:  
Thanks Joe

I got it figured now Wink

Using your test, although "C" shouldn't be there, but if it is we exit with a little message to set the locale.

Cheers

Mick
_________________
keep the faith Cool ..
Back to top
View user's profile Send private message Visit poster's website 
potong

Joined: 06 Mar 2009
Posts: 88
PostPosted: Sat 22 May 2010, 23:14    Post subject:  
01micko:

I think this bash code:
Code:
#set language
[ $LANGUAGE = auto ] && TMP="`ls -1 $APPDIR/locals/ | grep $LANG`"
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[ "$TMP" != "en_US:english" ] && . $APPDIR/locals/$TMP 2> /dev/null

can be simplified to:
Code:
#set language
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[[ $LANGUAGE = auto && -f $APPDIR/locals/$LANG ]] && . $APPDIR/locals/$LANG 2> /dev/null

If the user wants he can cd to his locale directory, copy the default locale and edit in his own messages and then rename the file the same as his $LANG and it will overwrite the default locale (i.e. en_US:english) messages automatically.

BTW: the [[ ... ]] (in bash) is a little more flexible than [ ... ] and often or not, does as you would expect; see here and here.
HTH

Potong
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 7018
Location: qld
PostPosted: Mon 24 May 2010, 18:50    Post subject:  
Thanks potong

Ok, Here's what I have so far now, and it seems to work ok for those who have tried

Code:
#set language
DEFLANG=`env|grep "LANG="`
if [ "$DEFLANG" = "LANG=C" ];then xmessage -center "Please set your locale" &
exit
fi
LANGUAGE=`echo $LANG|head -c5` #workaround for utf8
TMP="`ls $APPDIR/locals/ | grep $LANGUAGE`"
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[[ "$TMP" != "en_US:english" ]] && . $APPDIR/locals/$TMP 2> /dev/null


There was a problem if utf8 is set where "env|grep LANG" would return ${LANGUAGE}.utf8. This would bork because the rc files are all named by the same name as in "set locale".

Also, to be clear, I am not using zigbert's LANGUAGE=auto because this script is run early, where a user has not the chance to change language.. and most likely wouldn't want to.. see here

(sidenote: if you look at the script I had to perform some gtk-dialog gymnastics to work around issues with Fribidi in yaf-splash and xmessage Wink . Any advice/improvements welcome)

Cheers

EDIT The code above actually introduced a mozilla-GTK bug. Other browsers, Opera and Chromium were fine.

Here's the change, and I only had a hunch, got lucky I guess. Rolling Eyes Laughing

Code:
#set language
DEFLANG=`env|grep "LANG="`
if [ "$DEFLANG" = "LANG=C" ];then xmessage -center "Please set your locale" &
exit
fi
LANGUAGE=`echo $LANG|head -c5` #workaround for utf8
TMPLANG="`ls $APPDIR/locals/ | grep $LANGUAGE`"
. $APPDIR/locals/en_US:english #always run to fill gaps in translation
[[ "$TMPLANG" != "en_US:english" ]] && . $APPDIR/locals/$TMPLANG 2> /dev/null


changed TMP to TMPLANG

I have no idea why it worked!
_________________
keep the faith Cool ..
Back to top
View user's profile Send private message Visit poster's website 
Karl Godt


Joined: 20 Jun 2010
Posts: 2675
Location: Kiel,Germany
PostPosted: Wed 16 Feb 2011, 19:34    Post subject:  
Code:
A=20
 if test xA = x20; then echo hallo;fi
 if test x$A = x20; then echo hallo;fi

Quote:
hallo

from BruceB Text-User-Interface-Tutorial

About `ls` : it likes to echo errors , so you will still have some input , even if the file is not found , so doing a `grep` should be fine .

About REG-EXPR : These are not literally regular expressions, but extended command options/parameters, so a ':' might be a problem at some shells/bashs/xterm-variants :
Code:
A="ABCabc 123 43"
echo ${A:3:5}

Quote:
abc 1
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 3843
PostPosted: Thu 17 Feb 2011, 16:10    Post subject:  
setting languages is good for a case statement

Code:
case $LANG in
  es*)export PO1="..."
  ;;
  C|en*)export PO1=",,,"
  ;;
  *)export PO1="default values"
  ;;
esac

i actually just set up a function for each language

Code:
app_lang_default() { export VAR1="default values" ...; }
app_lang_en_US () { export VAR1="" ....; }

and then call it with:

Code:
app_lang_default #set default values in case in $LANG incomplete or nonexistent
app_lang_$LANG #in script functions are ~20X faster than  a separate file

this has the advantage of being able to add translations in increments fairly easily, since anything that is not yet translated automatically gets the default values

there are several ways to skin the cat
if speed is not a concern as much as size, you could use separate language files and include them like this:
Code:
. /usr/share/locale/$LANG/myapp.po

where myapp.po contains export VAR="....
_________________
Puppy Web Desktop Now with pet packages - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
big_bass


Joined: 13 Aug 2007
Posts: 1736
PostPosted: Sun 18 Dec 2011, 11:48    Post subject:  
if speed is a need lets try it in C code

*I would just use BaCon though because its easy to read

lang-example.c

Code:
/* getenv example: getting Lang */
#include <stdio.h>
#include <stdlib.h>

int main ()
{
  char * LANG_used;
  LANG_used = getenv ("LANG");
  if (LANG_used!=NULL)
    printf ("The current LANG is: %s",LANG_used);
  return 0;



}



# time ./lang-example
The current LANG is: en_US
real 0m0.031s
user 0m0.016s
sys 0m0.008s
_________________
slackware 14
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 3843
PostPosted: Mon 19 Dec 2011, 04:52    Post subject:  
Not really... using a C binary from a shell script would actually be slower than using shell built-ins because it has to source, load and run the compiled C binary, whereas the shell is already sourced, loaded and running and the shell code when compressed is typically much smaller than even the mandatory elf bits - not including the rest of the code. I have tested this before - which is why I wrote jwm_menu_create in straight shell (which runs fully localized in not much more time than that small amount of C and does a _lot_ of work)

Note that sed, grep, cut, tr and awk etc... are not shell builtins, but if, then, else, for, while, case, test, echo, functions and variables etc... are.

For it to be faster it would have to be a significant amount of data (on the scale of 100+ times more data) or the whole thing would need to be in C.

This varies depending on your shell of course, the busybox shells (ash/hush) are typically over twice as fast as bash3 and ~3 times faster than bash4 - dash is smaller yet still a bit slower than busybox shells when using builtins for whatever reason.
_________________
Puppy Web Desktop Now with pet packages - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
big_bass


Joined: 13 Aug 2007
Posts: 1736
PostPosted: Mon 19 Dec 2011, 10:34    Post subject:  
Quote:
or the whole thing would need to be in C.


here is just my opinion
however BaCon syntax is more "readable"
quick to develop in and the result
is an app that is compiled in C and fast


why ?
I replaced almost all of busyboxes' links with the real
apps this way updating and maintaining compatibility
with the linux community is just too easy

for me is busybox and any ( hybrid of it ) is just a cut down tool a good tool "but"
the farther you go away from standardized linux tools
the farther you will need to return someday ...

time will tell

Joe
_________________
slackware 14
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 2675
Location: Kiel,Germany
PostPosted: Tue 20 Dec 2011, 18:00    Post subject:  
Quote:
for me is busybox and any ( hybrid of it ) is just a cut down tool a good tool "but"

Short note not relevant to the theme of the thread :
Busybox is quite OK , BK configures it small .
If you enable all compressions in busybox you will get a busybox that is capable of modprobe 'ing other than ko.gz .
I also tried to adjust the makefiles in modprobe source to compile not only insmod statically but failed .
In my honest opinion busybox modprobe is superior to the FULL modprobe .
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 1 of 1 [11 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

[ Time: 0.0826s ][ Queries: 12 (0.0131s) ][ GZIP on ]