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