>>> 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
-------------------------------------------------------
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_id=6595&alloc_id=14396&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=2995
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
