Codex

Locale::gettext_dumb

Section: User Contributed Perl Documentation (3pm)

Updated: 2013-01-23

Index?action=index Return to Main Contents


NAME

Locale::gettext_dumb - Locale unaware Implementation of Uniforum Message Translation

SYNOPSIS

DESCRIPTION

IMPORTANT! This module is experimental. It may not work as described!

The module Locale::gettext_dumb does exactly the same as (3pm) or (3pm).

While both other modules use POSIX::setlocale() to determine the currently selected locale, this backend only checks the environment variables LANGUAGE, LANG, LC_ALL, LC_MESSAGES (in that order), when it tries to locate a message catalog (a .mo file).

This class was introduced in libintl-perl 1.22.

USAGE

This module should not be used for desktop software or scripts run locally. Why? If you use a message catalog for example in Danish in UTF-8 (da_DA.UTF8) but the system locale is set to Russian with KOI8-R (ru_RU.KOI8-R) you may produce invalid output, either invalid multi-byte sequences or invalid text, depending on how you look at it.

That will happen, when you mix output from Locale::gettext_pp with locale-dependent output from the operating system like the contents of the variable ``$!, date and time formatting functions (localtime(), gmtime(), POSIX::strftime() etc.), number formatting with printf()'' and friends, and so on.

A typical usage scenario looks like this:

You have a server application (for example a web application) that is supposed to display a fixed set of messages in many languages. If you want to do this with (3pm) or (3pm), you have to install the locale data for all of those languages. Otherwise, translating the messages will not work.

With (3pm) you can relax these requirements, and display messages for all languages that you have mo files for.

On the other hand, you will soon reach limits with this approach. Almost any application requires more than bare translation of messages for localisation. You want to formatted dates and times, you want to display numbers in the correct formatting for the selected languages, and you may want to display system error messages (``$!'').

In practice, (3pm) is still useful in these scenarios. Your users will have to live with the fact that the presented output is in different languages resp. for different locales, when ``their'' locale is not installed on your system.

More dangerous is mixing output in different character sets but that can be easily avoided. Simply make sure that Locale::gettext_dump uses UTF-8 (for example by setting the environment variable OUTPUT_CHARSET or by calling bind_textdomain_codeset()) and make sure that the system locale also uses UTF-8, for example `en_US.UTF8. If that fails, switch to a locale that uses a subset of UTF-8. In practice that will be US-ASCII, the character set used by the default locale ``C resp. ``POSIX''.

Your application will then to a certain extent mix output for different localisations resp. languages. But this is completely under your control.

EXAMPLE

See above! Normally you should not use this module! However, let us assume you have read the warnings. In a web application you would do something like this:

If your application forces the usage of UTF-8 you should ignore the environment variable

AUTHOR

Copyright (C) 2002-2013, Guido Flohr <[email protected]>, all rights reserved. See the source code for details.

This software is contributed to the Perl community by Imperia (<http://www.imperia.net/>).

SEE ALSO

(3pm), (3pm), (3pm), (3pm), (3pm), perl?(1), gettext?(1), gettext?(3)


Index

NAME

SYNOPSIS

DESCRIPTION

USAGE

EXAMPLE

AUTHOR

SEE ALSO