[rt-devel] Re: RT 3.0.1 I18N patch proposal

[Jesse Vincent]

Thanks very much for this. I expect to have real net again on wednesday
or thursday and will test it out then. In the meantime, I'd love to hear
others' reports on how this patch fixes things up?

	Thanks again,
	jesse


On Tue, May 06, 2003 at 02:39:44PM +0200, Remy Chibois wrote:
> 
> 
> Hello everybody,
> 
> here's a small patch for RT 3.0.1 which tries to correct some issues
> people (including me) are having with international characters.
> 
> My setup is:
> 	- RedHat 7.3
> 	- Perl v5.8.0 built for i686-linux-thread-multi
> 	- Apache/1.3.27 with mod_perl/1.27
> 	- RT 3.0.1
> 
> "Encodings" setup in RT_SiteConfig.pm is:
> 
> @EmailInputEncodings = qw(iso-8859-1) unless (@EmailEncodings);
> Set($EmailOutputEncoding , 'iso-8859-1');
> 
> 
> To install it, cd into your RT 3.0.1 installation and type:
> 
> 	cat rt-3.0.1-I18N.patch.gz | gunzip | patch -p1
> or
> 	zcat rt-3.0.1-I18N.patch.gz | patch -p1
> 
> depending on your setup.
> 
> 
> The patch modifies the following files:
> 
> --> lib/RT/EmailParser.pm
> 
> When a mail "Subject" contains international characters, it will normally
> be encoded in "MIME words" format. RT already addresses this but not for
> the "To" and "CC" fields. The patch corrects this.
> 
> 
> --> lib/RT/I18N.pm, lib/RT/Action/SendEmail.pm
> 
> Attachments whose filenames contain international characters are also encoded
> in "MIME words" format. These MIME attributes were not decoded in RT and
> attachments appeared "MIME words" encoded in the web interface.
> 
> 
> --> lib/RT/I18N.pm
> 
> It was observed that M$ Outlook oddly encodes some MIME fields and attributes.
> RT already handles the substitution for a blank space encoded as an underscore,
> but in some cases (espcially when the field is more than 40 characters),
> multiple "MIME words" lines appear, separated by a newline followed by a tab.
> The patch will add some more substitutions for this special case.
> 
> 
> --> lib/RT/Record.pm
> 
> Perl internal Encode::decode_utf8 function completely mangles text if it's
> not in utf8 and contains international characters. In my case, data entered
> in web forms was not sent in utf8 format and the converted string was set to
> '0'.
> 
> 
> As usual, please make a backup before applying this patch.
> 
> In the hope this will be useful,
> 
> -- 
>     Remy Chibois



-- 
http://www.bestpractical.com/rt  -- Trouble Ticketing. Free.