« Return to Thread: Change of SM default_charset to UTF-8
Re: Change of SM default_charset to UTF-8
by Bugzilla from nice@titanic.nyme.hu
::
Rate this Message:
On 2009. május 2. 16.24.33 Fredrik Jervfors wrote:
> > Hi all,
> >
> > seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18,
> > I'd like to propose to switch the SM's default_charset to UTF-8 as well.
> >
> > The definition for it resides in config/config_default.php and I suggest
> > to modify it as follows:
> >
> > ------------------
> >
> > /**
> > * Default Charset
> > *
> > * This option controls what character set is used when sending mail
> > * and when sending HTML to the browser. By default it's set to 'utf-8',
> > * which ensures that mail written in any charset could be handled
> > correctly. *
> > * This option is active *ONLY* when default language is en_US. In other
> > * cases SquirrelMail uses charset that depends on default language.
> > * See $squirrelmail_default_language
> > *
> > * If you're seeing any strange problems with UTF-8, you might try to set
> > * the default charset to 'iso-8859-1'.
> > * @global string $default_charset
> > */
> > $default_charset = 'utf-8';
> >
> > ----------------------
> >
> > The above change will have zero impact on existing installations, since
> > this template file is used just for fetching defaults during first SM
> > installation. Anyway, I do belive that setting this to UTF-8 is a good
> > way to express our common preference for UTF-8 and initiate migration
> > towards it.
> >
> > What do you think?
>
> Personally I like it, Miro. It has been discussed before and it can
> certainly be done in the development version. As for 1.4.18 I'm not sure.
> I'd like to have some testing time in 1.5.2 SVN first.
>
> What do the rest of the list think? If I see no objections I'll go ahead
> and commit your suggested change to 1.5.2.
Dear all!
My experiences are the following:
-Since the .mo files contain charset information, it's probably not too
dangerous to convert these files to any charset (utf-8, for example).
(However, I observed the change_pass plugint to be confused by the LOCALE
value of the language, hence handling its .mo file's charset incorrectly.)
-Mails, themselves (if they are correcly composed) also contain the necessary
encoding information, so SM is capable to display any mail running with any
charset setting (by the &#N; HTML mechanism).
-User data (username, password, .pref files and similar databases) doesn't
contain charset information, and my suspicion is that it's unconditionally
handled according to the current language's CHARSET value. I think this means
that when you change a language's charset during a version change, all the
user data containing non-english characters will become unusable. Names in
addressbook, the user's own name etc. has to be converted, but it's even worse
that passwords containing accentuated caracters will also become invalid, so
the sysadmin and the user has to change it cooperatively!
I think, changing a language's charset to utf-8 is dangerous because of this,
but changing only the default_charset may be safe since english language users
don't have too much accentuated characters amongst their user data (maybe some
french, german, spaninsh, scandinaivian names in their address books, which
have to be converted after changing the default charset).
I think it would be more useful for non-english users to enable lossy_encoding
somehow, since it makes possible to correclty answer utf-8 encoded (but not
foreign language) messages.
Instead of switching every language to utf-8, I would suggest to enable system
admins to set the charset for the currently used language, not just the
default_charset, and in addition, sysadmins should be warned that changing
this value on an existing installatiin may make it necessary to convert all
user data.
Sincerely,
Tamás
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
squirrelmail-i18n mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
Information about translations: http://squirrelmail.org/wiki/LanguageTranslation
Statistics for translations: http://l10n-stats.squirrelmail.org/
List address: squirrelmail-i18n@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n
> > Hi all,
> >
> > seeing that 3 more languages are going to switch to UTF-8 for SM 1.4.18,
> > I'd like to propose to switch the SM's default_charset to UTF-8 as well.
> >
> > The definition for it resides in config/config_default.php and I suggest
> > to modify it as follows:
> >
> > ------------------
> >
> > /**
> > * Default Charset
> > *
> > * This option controls what character set is used when sending mail
> > * and when sending HTML to the browser. By default it's set to 'utf-8',
> > * which ensures that mail written in any charset could be handled
> > correctly. *
> > * This option is active *ONLY* when default language is en_US. In other
> > * cases SquirrelMail uses charset that depends on default language.
> > * See $squirrelmail_default_language
> > *
> > * If you're seeing any strange problems with UTF-8, you might try to set
> > * the default charset to 'iso-8859-1'.
> > * @global string $default_charset
> > */
> > $default_charset = 'utf-8';
> >
> > ----------------------
> >
> > The above change will have zero impact on existing installations, since
> > this template file is used just for fetching defaults during first SM
> > installation. Anyway, I do belive that setting this to UTF-8 is a good
> > way to express our common preference for UTF-8 and initiate migration
> > towards it.
> >
> > What do you think?
>
> Personally I like it, Miro. It has been discussed before and it can
> certainly be done in the development version. As for 1.4.18 I'm not sure.
> I'd like to have some testing time in 1.5.2 SVN first.
>
> What do the rest of the list think? If I see no objections I'll go ahead
> and commit your suggested change to 1.5.2.
Dear all!
My experiences are the following:
-Since the .mo files contain charset information, it's probably not too
dangerous to convert these files to any charset (utf-8, for example).
(However, I observed the change_pass plugint to be confused by the LOCALE
value of the language, hence handling its .mo file's charset incorrectly.)
-Mails, themselves (if they are correcly composed) also contain the necessary
encoding information, so SM is capable to display any mail running with any
charset setting (by the &#N; HTML mechanism).
-User data (username, password, .pref files and similar databases) doesn't
contain charset information, and my suspicion is that it's unconditionally
handled according to the current language's CHARSET value. I think this means
that when you change a language's charset during a version change, all the
user data containing non-english characters will become unusable. Names in
addressbook, the user's own name etc. has to be converted, but it's even worse
that passwords containing accentuated caracters will also become invalid, so
the sysadmin and the user has to change it cooperatively!
I think, changing a language's charset to utf-8 is dangerous because of this,
but changing only the default_charset may be safe since english language users
don't have too much accentuated characters amongst their user data (maybe some
french, german, spaninsh, scandinaivian names in their address books, which
have to be converted after changing the default charset).
I think it would be more useful for non-english users to enable lossy_encoding
somehow, since it makes possible to correclty answer utf-8 encoded (but not
foreign language) messages.
Instead of switching every language to utf-8, I would suggest to enable system
admins to set the charset for the currently used language, not just the
default_charset, and in addition, sysadmins should be warned that changing
this value on an existing installatiin may make it necessary to convert all
user data.
Sincerely,
Tamás
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
-----
squirrelmail-i18n mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
Information about translations: http://squirrelmail.org/wiki/LanguageTranslation
Statistics for translations: http://l10n-stats.squirrelmail.org/
List address: squirrelmail-i18n@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.internationalization
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-i18n
« Return to Thread: Change of SM default_charset to UTF-8
| Free embeddable forum powered by Nabble | Forum Help |
