Date: Mon, 11 Apr 2005 19:18:54 +0200 (EET)

Subject: Re: [SM-USERS] Re: Re: Re: Sending Japanese Characters
From: "Tomas Kuliavas" <[EMAIL PROTECTED]>
To: [email protected]



I changed these lines in i18n.php
<code>
$languages['en_US']['NAME']    = 'English';
$languages['en_US']['CHARSET'] = 'utf-8';
$languages['en_US']['LOCALE']  = 'en_US.utf-8';
$languages['en']['ALIAS']      = 'en_US';
</code> Was I changing the wrong lines or is there something else I
need to change? My problem is I have a number of bi-lingual users
who's first language is English but have to communicate with customers
in Japanese they would rather see a English interface even though they
read/write Japanese. Thanks Again, Erin



You have changed different squirrelmail install or RH changed something
in squirrelmail i18n. Your changes should have set US English translation
to utf-8 charset. Which charsets are used in your emails? iso-2022-jp,
euc-jp, some other charset. Which extensions are supported by your php
install? I need information about iconv and recode support. Which php
version is used? Can you check if you can write in Japanese when
Lithuanian or Russian translations are used. If lt_LT and ru_RU
locales are not installed, interface will remain in English. Don't try to
reply to other Japanese email. Only write in Japanese and check if others
can read it. Can you create utf-8 encoded html page with all Kanji,
Hirigana and Katakana characters and check if your browser
displays them correctly? -- Tomas



Tomas-


First let me apologize for the delay in my response I was dragged away to work on a Windows project for a week or so.

PHP Version php-4.3.10-2.4
I am sorry I do not know what you mean by iconv and recode I searched for
them on my system and in a the code sent back from my php info page and
did not see them.

I sent a mail from the Lithuanian interface of my Squirrelmail and it
appears fine like and uses UTF-8 here is the header:

User-Agent: SquirrelMail/1.4.4-1.FC2
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on
localhost X-Virus-Status: Clean




When I tried to change the English to UTF-8 it gives me broken text again. It is still including this header which has charset=iso-8859-1. If I manually change the encoding to UTF-8 in the users mail program and the text appears correctly in (Thunderbird or OE) (After it is sent from SquirrelMail)


User-Agent: SquirrelMail/1.4.4-1.FC2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on localhost X-Virus-Status: Clean Status:


æ


ãããã


ããã


æåæ


ããããããããããã


I can create UTF-8 pages and post them on the server and they read correctly.

Japanese mail is ussually encoded in iso-2022-jp and that will handle all
Kanji, Hirigana, and Katakana.
But UTF-8 will work for most everything as well.


2 points of interest ***I am sure others know this file much better than I do but here goes*** I found this in while searching for en_US

// Catch removed translation
if (!isset($languages[$my_language])) { $my_language="en_US";
}
while (isset($languages[$my_language]['ALIAS'])) { $my_language =
$languages[$my_language]['ALIAS'];
}
$my_charset = $languages[$my_language]['CHARSET'];
if ($my_language!='en_US') { $default_charset = $my_charset;




And I also note there was a extra line associated with Japanese XTRA_CODE


$languages['ja_JP']['NAME'] = 'Japanese'; $languages['ja_JP']['CHARSET'] = 'iso-2022-jp'; $languages['ja_JP']['XTRA_CODE'] = 'japanese_charset_xtra'; $languages['ja']['ALIAS'] = 'ja_JP';


Does anyone have any other thoughts on this?



http://www.php.net/iconv http://www.php.net/recode In order to read Eastern charsets without toasting your server, squirrelmail needs external functions that support convertions to html entities. In some cases conversion to utf-8 works too. Convertion to html entities can be implemented in php recode extension (ussually not enabled due to conflicts with imap extension) or php 4.3+ mbstring extension (i suspect it does not cover some Japanese chars). Conversion to utf-8 can be implemented in php recode, iconv or mbstring extensions. I might try implementing it in external conversion program too.

Japanese translation uses XTRA_CODE functions to override default behavior
of squirrelmail functions. Used code converts composed emails to
iso-2022-jp, uses mb_encode_mimeheader() to encode headers to B encoding
instead of Q encoding used in squirrelmail by default, converts headers
and body between different Japanese charsets.

You have posted code from set_up_language() function, which sets charset
used by translation and makes sure that translation exists in $languages
array. It can break custom_charset plugin only when code tries to setup
language environment by loading only functions/i18n.php. I think plugin
coding guidelines talk about including include/validate.php and not
functions/i18n.php. In cases when include/validate.php can't be loaded,
user is not authenticated and it does not matter which charset is used for
English language. Only 8bit passwords can be affected.

If you use custom_charset plugin, remember that there are two English
entries in Options -> Display Preferences -> Language. Custom charset
works only with "English (custom charset)".

If you use custom_charset plugin with utf-8 charset and language is
"English (custom charset)", or modify functions/i18n.php to

$languages['en_US']['NAME']    = 'English';
$languages['en_US']['CHARSET'] = 'utf-8';
$languages['en_US']['LOCALE']  = 'en_US.UTF-8';
$languages['en']['ALIAS'] = 'en_US';

English interface operates in utf-8. Tested with 1.5.1cvs and 1.4.4. Only
difference - you don't see custom_charset trailing text in 1.4.4.

If you use en_US as default language, you can also make sure that
squirrelmail configuration stores utf-8 as default charset. In some
squirrelmail versions we have implemented calls that keep $default_charset
value from squirrelmail configuration, when default language is en_US. I
think it is not implemented in vanilla 1.4.4 and I think fedora developers
only readded translations, modified strings.php, rearranged files and
changed some lines in help files in 1.4.4-1.FC2 package. I can't see other
code modifications in diff -urNw.

I might need list and order of installed plugins and any information about
modifications made to squirrelmail, in order to reproduce your problem
($languages stores en_US in utf-8, $default_charset stores utf-8 and
interface is still in iso-8859-1).


Tomas,

Thanks again,
The server and installation are as follows
Installed FC2 from CDs and during installation. During the installation I choose the following packages in the mail section.
Sendmail, Squirrlemail, and Dovecot. I have not added or modified any packages associated with that except through YUM update. All other packages were installed via YUM or during the initial installation with the exception of MySQL which was a RPM installs of these packages
MySQL-client-4.1.10a-0
MySQL-shared-compat-4.1.10a-0
mysql-query-browser-1.1.6-1.rh9
MySQL-server-4.1.10a-0
MySQL-devel-4.1.10a-0
MySQL-shared-4.1.10a-0
mysql-administrator-1.0.19-1.rh9
MySQL-embedded-4.1.10a-0
php-mysql-4.3.10-2.4


Which brought me to my current state of :
kernel-2.6.10-1.770_FC2
php-ldap-4.3.10-2.4
php-imap-4.3.10-2.4
php-mbstring-4.3.10-2.4
php-pear-4.3.10-2.4
php-4.3.10-2.4
php-mysql-4.3.10-2.4
squirrelmail-1.4.4-1.FC2
system-config-httpd-1.2.0-3
httpd-devel-2.0.51-2.9
httpd-2.0.51-2.9
httpd-manual-2.0.51-2.9
dovecot-0.99.13-4.FC2
sendmail-8.12.11-4.6
sendmail-devel-8.12.11-4.6
sendmail-cf-8.12.11-4.6
sendmail-doc-8.12.11-4.6
clamav-0.83-1
clamav-devel-0.83-1
clamav-milter-0.83-1
spamassassin-2.63-8
procmail-3.22-13


I know that the last few packages may seem unessacary but I am trying to include everything that touches the mail.
My attempt is to build a vanilla server that is easy to maintain but still feature rich and can be deployed around the world and support any user in any local (although my to main local concerns are Japan and the US).


Thanks again.
Erin

Thanks for your assistance,

Erin




------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- squirrelmail-users mailing list Posting Guidelines: http://squirrelmail.org/wiki/wiki.php?MailingListPostingGuidelines List Address: [email protected] List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.user List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id)95 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users

Reply via email to