unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Kevin Ryde <user42@zip.com.au>
Cc: Bruno Haible <bruno@clisp.org>
Subject: doc gettext
Date: Mon, 10 Jan 2005 09:48:27 +1100	[thread overview]
Message-ID: <873bxarzgk.fsf@zip.com.au> (raw)

I'm looking at the text below to expand what's in the guile reference
manual for gettext.  It adds some examples and some bits of advice.

I'm a bit unsure about bind-textdomain-codeset.  Thinking about it, if
Guile gets its own notion of coding systems or whatever in the future
then I'm wondering if that function might become obsolete, or even
actively harmful.  It does some good now, but maybe some strong
warning against possible future change is needed.




5.20 Support for Internationalization
=====================================

Guile provides an interface to GNU `gettext' for translating message
strings (*note Introduction: (gettext)Introduction.).

   Message domains allow messages from different programs or libraries
to be kept separate.  A domain is just a string (it becomes part of the
message catalog filename).

   When `gettext' is not available, or if Guile was configured
`--without-nls', dummy functions doing no translation are provided.

 -- Scheme Procedure: gettext msg [domain [category]]
 -- C Function: scm_gettext (msg, domain, category)
     Return the translation of MSG in DOMAIN.  DOMAIN is optional and
     defaults to the domain set through `textdomain' below.  CATEGORY
     is optional and defaults to `LC_MESSAGES'.

     If a program has many messages, a shorthand can be created.  `_'
     is usual for this, and is recognised by `xgettext' (*note Invoking
     the `xgettext' Program: (gettext)xgettext Invocation.).

          (define _ gettext)
          (display (_ "You are in a maze of twisty passages."))

     In a library the same can be done, but usually a domain should be
     given explicitly, so it will still work if an application makes
     itself as the default.

          (define (_ msg) (gettext msg "mylibrary"))
          (display (_ "File not found."))

     Such a shorthand is also a good place to perhaps strip
     disambiguating extra text from the message string, as per for
     instance *Note How to use `gettext' in GUI programs: (gettext)GUI
     program problems.

 -- Scheme Procedure: ngettext msg msg_plural n [domain [category]]
 -- C Function: scm_ngettext (msg, msg_plural, n, domain, category)
     Return the translation of MSG/MSG_PLURAL in DOMAIN, with the
     plural form chosen appropriately for the number N.  DOMAIN is
     optional and defaults to the domain set through `textdomain'
     below.  CATEGORY is optional and defaults to `LC_MESSAGES'.  For
     example,

          (define (done n)
            (format #t (ngettext "~a file processed\n"
                                 "~a files processed\n" n)
                       n))

     It's important to use `ngettext' for plurals, to allow translators
     to give the proper forms for various N in other languages.

 -- Scheme Procedure: textdomain [domain]
 -- C Function: scm_textdomain (domain)
     Get or set the default gettext domain.  When called with DOMAIN,
     it is set as the default, and that new value returned.  When called
     with no parameter the current domain is returned.  For example,

          (textdomain "myprog")
          => "myprog"

 -- Scheme Procedure: bindtextdomain domain [directory]
 -- C Function: scm_bindtextdomain (domain, directory)
     Get or set the directory under which to find message files for
     DOMAIN.  When called with a DIRECTORY, DIRECTORY is set for DOMAIN
     and that new setting returned.  When called without a DIRECTORY
     the current setting is returned.  For example,

          (bindtextdomain "myprog" "/my/tree/share/locale")
          => "/my/tree/share/locale"

     When using Autoconf/Automake, an application should arrange for the
     configured `localedir' to get into the program (by substituting,
     or generating a config file) and set that for its domain.  This
     ensures the catalog can be found even when installed in a
     non-standard location.

 -- Scheme Procedure: bind-textdomain-codeset domain [encoding]
 -- C Function: scm_bind_textdomain_codeset (domain, encoding)
     Get or set the text encoding to be used by `gettext' for messages
     from DOMAIN.  ENCODING is a string, the name of a coding system,
     for instance "8859_1".  (On a GNU system the `iconv' program can
     list all available encodings.)

     When called with an ENCODING, it is set for DOMAIN and that new
     setting returned.  When called without an ENCODING the current
     setting is returned, or `#f' if none yet set.  For example,

          (bind-textdomain-codeset "myprog")
          => #f
          (bind-textdomain-codeset "myprog" "latin-9")
          => "latin-9"

     The encoding requested can be different from the translated data,
     messages will be recoded as necessary.  But note that when there
     is no translation `gettext' returns its MSG unchanged, ie.
     without any recoding.  For that reason source message strings are
     best as plain ASCII.

     Currently Guile has no understanding of multi-byte characters, and
     string functions won't recognise character boundaries in multi-byte
     strings.  An application will at least be able to pass such strings
     through to some output though.  Perhaps this will change in the
     future.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


             reply	other threads:[~2005-01-09 22:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-09 22:48 Kevin Ryde [this message]
2005-01-10 21:11 ` doc gettext Bruno Haible
2005-01-23 23:20   ` Kevin Ryde
     [not found] ` <200501202239.07346.bruno@clisp.org>
     [not found]   ` <87d5vzd6bb.fsf@zip.com.au>
2005-01-21 12:09     ` building guile from CVS Bruno Haible
2005-01-21 14:06       ` Marius Vollmer
2005-01-21 15:41         ` Bruno Haible
2005-01-21 21:45           ` Kevin Ryde
2005-01-22 14:03             ` Marius Vollmer
2005-01-24 15:25             ` Bruno Haible
2005-02-28  1:17           ` Marius Vollmer
2005-02-28  1:31             ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=873bxarzgk.fsf@zip.com.au \
    --to=user42@zip.com.au \
    --cc=bruno@clisp.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).