Hi,

Writing an example script for Win32::MultiLanguage that simply lists
all supported code pages in the user's default language, I naturally got
all the umlauts in the german output messed up in the console. Wondering
how to fix that I thought there should be a simple way to say, e.g.,

binmode STDOUT => ':encoding(:terminal)' if -t STDOUT;

I only found the :locale sub-pragma in open.pm and encoding.pm and it
seems it does not work with binmode at all and would also fail on Win32
systems due to not setting the relevant environment variables. So I've
implemented a crude and simple solution like this:

use Encode;
use Encode::Alias;

sub terminal_encoding {
my $encoding;

I'm trying to strip out combining diacritics from some form input using this code:

#!/usr/local/bin/perl
use CGI;
$query = CGI::new();
$search_term = $query->param('text');
$sans_diacritics = $search_term;
$sans_diacritics =~ s/\p{M}*//g;
#$sans_diacritics =~ s/o//g;
print qq(Content-type: text/plain; charset=utf-8

Dear whoever is using Locale::Maketext::Gettext,

Locale::Maketext::Gettext 1.24 is released, after another year.
This release adds support for GNU gettext pgettext() as pmaketext(), to
translate messages in a particular context.

Thanks to Chris Travers gmail.com> for the suggestion.
I was away from the GNU gettext development for too long.

GNU gettext pgettext() (and hence pmaketext()) is an important
improvement for GUI applications, which may have short menu items that
are ambiguous to translators without its menu context. If you do not
know what is "context", refer to:

11.2.5 Using contexts for solving ambiguities
http://www.gnu.org/software/gettext/manual/gettext.html#Contexts

Effectively, failure_handler_auto() differs from its
Locale::Maketext parent method from now on.

Please tell me if there is any problem. Your feedbacks are welcome.
Thank you.

I believe that format is RFC 2047 Mime Header Encoding, try the
Encode::MIME::Header module to decode it
http://perldoc.perl.org/Encode/MIME/Header.html

- - Martin

-----Original Message-----
From: Neil Gunton [mailto:neil@nilspace.com]
Sent: Saturday, January 12, 2008 19:18
To: perl-i18n@perl.org
Subject: Problem processing UTF-8 strings from email

Hi all,

I am somewhat experienced with Perl in general, but absolutely no
experience dealing with UTF-8. I have a community journals website which

allows updates from users via email. I'm having trouble with emails that

contain Chinese characters encoded (I think) as UTF-8. The strings look
like this:

=?UTF-8?B?5qGQ5LmhLCBUb25neGlhbmc6IEJlaW5nIGEgJ2hhbg==?=
=?UTF-8?B?dHUn?=

John ORourke wrote:

For the GNU libc locale definitions see
http://mail.nl.linux.org/linux-utf8/2005-02/msg00033.html

Regards,
Guido

On Sunday 13 May 2007 17:14:43 you wrote:

All -

I'm having a problem that perhaps someone here can cast some light on.
For a very long time, a project I work on has been using GNU recode 3.6
to transcode a wide range of encodings into UTF-8, including some of the
more common Korean, Japanese and Chinese encodings (e.g., SJIS, gb2312,
EUC-KR). For efficiency reasons, we've been looking at moving to the
Perl Encode module, which we already use for windows-1252 because of
corruption issues with Arabic with GNU recode.

I compared a batch of about 120,000 documents for which I had both the
original and the output of GNU recode, and discovered a (relatively
small) number of differences, say about 4K documents. In almost all of
those cases, Perl recode appears to be inferior. The vast majority of
the differing documents are gb2132; however, many of the other Asian
encodings have sporadic problems. When I examine the documents for
differences, I typically find that Perl recode has introduced some stray
"unknown" characters at various points in the document, while the GNU
recode version is clean.

Hello list,
we have used Debian (3.1) Sarge for almost 2 years on our serverand everything
was encoded in UTF-8.

When Debain Etch (4.0) came out we read that everything in Etch now defaults
to UTF-8 character encoding so we decided to upgrade from from Sarge to Etch.

Sarge
====
Kernel 2.4.27
Apache 2.0.54
mysql 4.0.24
Perl 5.8.4

Etch
====
Kernel 2.6.18
Apache 2.2.3
mysql 5.0.32
Perl 5.8.8

Unfortunately after the upgrade the character encoding on our website was
messed up and it looks like the reason for that is PERL.

Dear whoever is using Locale::Maketext::Gettext,

Locale::Maketext::Gettext 1.21 is released, after two years. There
are several improvements. The majors improvements are:

1. The lookup failure handling mechanism is completely rewritten to
follow the Locale::Maketext's way. $lh->fail_with() and $lh->{"fail"}
in Locale::Maketext is wroking in Locale::Maketext::Gettext now.

This is caused by the fact that I did not read the documentation
of Locale::Maketext throughly. ^^; But since the previous lookup
failure handling mechanism was completely different, it has successfully
avoided bug#33938 and bug#25877:

https://rt.perl.org/rt3/Ticket/Display.html?id=33938
https://rt.cpan.org/Public/Bug/Display.html?id=25877

2. There is a fixed failure_handler_auto() method that override its
parent in Locale::Maketext, that fixes bug#33938 and bug#25877. You may
enjoy this fixed failure_handler_auto() if you use
Locale::Maketext::Gettext over Locale::Maketext. :p

3. Some encoding mess-up caused by my attempt to play magic in the
previous version was fixed.