Well, We completely separate out our content, from our presentation templates, from our source. We use HTML::Mason mostly as a layer of abstraction to mod_perl's raw API, and then use HTML::Template to munge our content with our templates in pre-release batch mode and/or dynamically.
We keep all of our strings in versioned content files, in XML format, something like the following: <str id="landHelp.004"> <content>Here's how to do it:</content> </str> ... <str id="commChat.217"> <content>How to participate</content> </str> This is an example of a US English XML string file. All of the different locales we support have their own string files, with the base being the US English one, meaning we always translate enUS -> other locale. So, for the traditional Chinese XML file, we would have the equivalent strings for those example stringIDs in-between the <content></content> tags, but in Chinese, the same for Polish, etc. Then, a template might look like: <option value="-1">------------------</option> <option value="-2"><!-- TMPL_VAR NAME=landHelp.004 --></option> ... etc. This is just HTML::Template syntax inside of a standard HTML template. The post-munging phase would be: <option value="-1">------------------</option> <option value="-2">Here's how to do it:</option> So, whenever we read in our string files for munging with templates, we tell Perl that the file is UTF-8 formatted, by creating the file handle as such, and that's it really; internally Perl automatically treats that string content as UTF-8 unless we state otherwise explicitly. We use the Encode module all the time to convert between UTF-8 and Big-5, or ISO-8859-2, or whatever for email templates with the same content. Of course in your web page templates, you have to have your character encoding set properly as well as in your emails for this all to work with respective clients. Apache really doesn't care, it just sees 8-bit data and serves it to the client. I also have the following set in the ENVironment of the user running apache, but I've completely commented it out and I see no difference in behavior, but I keep in there for posterity I guess ... :-) # Perl Unicode Support # This ENV will force the entire Perl interpreter in Apache to have the # following IO layers/streams forced to use UTF-8 as the desired charset. # See `perldoc perlrun` and `perldoc peruniintro` for more details. # I 1 STDIN is assumed to be in UTF-8 # O 2 STDOUT will be in UTF-8 # E 4 STDERR will be in UTF-8 # S 7 I + O + E # i 8 UTF-8 is the default PerlIO layer for input streams # o 16 UTF-8 is the default PerlIO layer for output streams # D 24 i + o # A 32 the @ARGV elements are expected to be strings encoded in UTF-8 # L 64 normally the "IOEioA" are unconditional, # the L makes them conditional on the locale environment # variables (the LC_ALL, LC_TYPE, and LANG, in the order # of decreasing precedence) -- if the variables indicate # UTF-8, then the selected "IOEioA" are in effect PERL_UNICODE=SDA export PERL_UNICODE It's important to understand how Perl deals with character data internally, and how it uses the UTF-8 flag it sets, etc. You should probably read up on it if you haven't at the following links: http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod http://search.cpan.org/~jhi/perl-5.8.0/pod/perlunicode.pod http://search.cpan.org/~dankogai/Encode-2.18/Encode.pm Hope this helps you out. - Jeff ----- Original Message ---- From: Jeff Pang <[EMAIL PROTECTED]> To: modperl@perl.apache.org Sent: Wednesday, April 4, 2007 7:20:01 PM Subject: Re: UTF-8 encoding problems under Apache 2 with mod_perl 2. > >We also do everything (not source code, which is in ISO-8859-1, only content) >in UTF-8 where I >work, and we support many different languages. Jeff,how did you do it by using utf-8 for everything?can you give a rough description?Thanks. -- mailto: [EMAIL PROTECTED] http://home.arcor.de/jeffpang/