🚀 go-pugleaf

Charlie Zender <zender@uci.edu> writes:

> I could not ever figure out what a PO file is but I know that
> I need one!

A PO file is a human-edited text file which lists original phrases and
their translations to some language.  It is then compiled to a MO file
with the msgfmt program.

To make a PO file, you first generate a POT file by using xgettext on
the program sources and then fill in the blanks.

> What should PACKAGE be? "gettext"?

PACKAGE should be the name of the program which uses gettext; in your
case, it might be "NCO".

> What about LOCALEDIR?

IIRC, it is usually ${datadir}/locale, as in /usr/share/locale.

> Where do I store the translations?

You type them in PO files, which you compile to MO files, which you
install in LOCALEDIR.  You should include the MO files in the source
package so that people can install it without msgfmt.  They'll work on
all architectures; if an OS vendor uses a different format for MO
files, that doesn't matter because they'll be read with the code in
intl/ of your package.

> Where is there a complete example of all this on the net?

I don't know.

Thanks for the info.

OK, after much trial and error I now have some i18n features implemented
in a single program


3 simple questions:
1. Where are discussions about i18n and l10n "on-topic"? is 
gnu.misc.discuss the right place? I could not find any active newsgroups
with discussions of i18n, bot comp.std.internat and 
comp.software.international seem inactive.

2. What do "po" and "mo" stand for? just curious

3. Currently I am testing my i18n features by invoking, e.g., export 
LANG=es at the command line. My spanish translation shows up fine, but
it uses, i think, the default RedHat 7 character set. How do I change
the character set in my xterms to be, say, iso-8859 so that things like
accented characters have a better chance of showing up correctly?
export LANG=es changes all of the LC_* tokens, but apparently the
xterm still uses the ascii character set. I want to know how to tell
a given xterm to really be a spanish/french/... xterm and use the 
correct character set and keyboard mapping.

Thanks,
Charlie
-- 
Charlie Zender zender@uci.edu (949) 824-2987/FAX-3256, Department of
Earth System Science, University of California, Irvine CA 92697-3100

Charlie Zender wrote:

> Thanks for the info.
> 
> 
> 2. What do "po" and "mo" stand for? just curious

PO = portable object (human readable text for input)
MO = machine object (compiled PO)
> 
> 3. Currently I am testing my i18n features by invoking, e.g., export
> LANG=es at the command line. My spanish translation shows up fine, but
> it uses, i think, the default RedHat 7 character set. How do I change
> the character set in my xterms to be, say, iso-8859 so that things like
> accented characters have a better chance of showing up correctly?
> export LANG=es changes all of the LC_* tokens, but apparently the
> xterm still uses the ascii character set. I want to know how to tell
> a given xterm to really be a spanish/french/... xterm and use the
> correct character set and keyboard mapping.

Somewhere I have read something like LANG=es.iso8859-1
but I am not sure about the details. Maybe you can find something on this 
in the man pages.

I don't know how the change the keyboard settings automagicly. I probably 
would use the regular keyboad mapping commands.
Cheers,

-- 
Koos Pol - Systems Administrator - Compuware Europe B.V. - Amsterdam
T:+31 20 3116122   F:+31 20 3116200   E:koos_pol@nl.compuware.com

Check my email address when you hit "Reply".

Charlie Zender <zender@uci.edu> wrote:

 > Currently I am testing my i18n features by invoking, e.g., export 
 > LANG=es at the command line. My spanish translation shows up fine, but
 > it uses, i think, the default RedHat 7 character set. How do I change
 > the character set in my xterms to be, say, iso-8859 so that things like
 > accented characters have a better chance of showing up correctly?
 > export LANG=es changes all of the LC_* tokens, but apparently the
 > xterm still uses the ascii character set.

LC_CTYPE and LC_MESSAGES are of main interest for you
but they _might_ need a slightly different syntax (es vs es_ES).

Inspect your fonts with xfd(1) and call xterm(1) with an appropriate one.
Find out about the location of your fonts via the fontpath, xset(1).

I once collected facts and hints for solving problems about the locale:
    <URL:http://www.uni-ulm.de/~s_smasch/Locale/>
(not struggling for completeness but just for inspiration)

f'up
Sven

/*
Demonstration of internationalization

--- begin - lang.po
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR Free Software Foundation, Inc.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: lang 0.1.0\n"
"POT-Creation-Date: 2001-02-02 11:55+0100\n"
"PO-Revision-Date: 2001-02-02 11:59+01:00\n"
"Last-Translator: Bart van Pelt <bart@vpelt.demon.nl>\n"
"Language-Team: NL <nl@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ISO-8859-1\n"
"Content-Transfer-Encoding: 8-bit\n"

#: lang.cxx:5
msgid "Start call_b"
msgstr "Start aanroep call_b"

#: lang.cxx:9
msgid "End  call_b with status "
msgstr "Einde aanroep call_b met status "

#: lang.cxx:16
msgid "Start call_a"
msgstr "Start aanroep call_a"

#: lang.cxx:22
msgid "End  call_a with status "
msgstr "Einde aanroep call_a met status "

#: lang.cxx:29
msgid "Start main"
msgstr "Start aanroep main"

#: lang.cxx:35
msgid "End  main with status "
msgstr "Einde aanroep main met status "
--- begin - lang.po

compile language definition
msgfmt -o lang.mo lang.po

place language specific file to correct place
LOCALEDIR = /usr/share/locale
PACKAGE = lang

cp lang.mo /usr/share/locale/nl/LC_MESSAGES

set environment variable
export LANG=nl

run program

$ lang

Start aanroep main
Start aanroep call_a
Start aanroep call_b
Einde aanroep call_b met status 3
Einde aanroep call_a met status 3
Einde aanroep main met status 3

unset lang

$ lang
Start main
Start call_a
Start call_b
End  call_b with status 3
End  call_a with status 3
End  main with status 3

*/

#include <locale.h>
#include <libintl.h>
#include <iostream>

#define PACKAGE "lang"
#define LOCALEDIR "/usr/share/locale"

int call_b(int pStatus)
{
  cout << gettext("Start call_b") << endl;

  int status = pStatus + 1;

  cout << gettext("End  call_b with status ") << status << endl;

  return status;
}

int call_a(int pStatus)
{
  cout << gettext("Start call_a") << endl;

  int status = pStatus + 1;

  status = call_b(status);

  cout << gettext("End  call_a with status ") << status << endl;

  return status;
}

int main(int argc, char * argv[])
{
  setlocale(LC_ALL, "");

  textdomain(PACKAGE);

  bindtextdomain(PACKAGE, LOCALEDIR);

  textdomain(PACKAGE);

  cout << gettext("Start main") << endl;

  int status = 1;

  status = call_a(status);

  cout << gettext("End  main with status ") << status << endl;

  return status;
}

In article <3A623AF2.6090302@uci.edu>,
  Charlie Zender <zender@uci.edu> wrote:
> Thanks for the info.
>
> OK, after much trial and error I now have some i18n features
implemented
> in a single program
>
> 3 simple questions:
> 1. Where are discussions about i18n and l10n "on-topic"? is
> gnu.misc.discuss the right place? I could not find any active
newsgroups
> with discussions of i18n, bot comp.std.internat and
> comp.software.international seem inactive.
>
> 2. What do "po" and "mo" stand for? just curious
>
> 3. Currently I am testing my i18n features by invoking, e.g., export
> LANG=es at the command line. My spanish translation shows up fine, but
> it uses, i think, the default RedHat 7 character set. How do I change
> the character set in my xterms to be, say, iso-8859 so that things
like
> accented characters have a better chance of showing up correctly?
> export LANG=es changes all of the LC_* tokens, but apparently the
> xterm still uses the ascii character set. I want to know how to tell
> a given xterm to really be a spanish/french/... xterm and use the
> correct character set and keyboard mapping.
>
> Thanks,
> Charlie
> --
> Charlie Zender zender@uci.edu (949) 824-2987/FAX-3256, Department of
> Earth System Science, University of California, Irvine CA 92697-3100
>
>


Sent via Deja.com
http://www.deja.com/