[SM-I18N] i18n.php may need to be rewritten.

[Kerem E. <ker...@ha...>]

Hi everyone,

Tomas wrote,
>
> I think Turkish iso-8859-9 and windows-1254 decoding is not correct
> (functions/i18n.php v.1.98.2.10). Maybe Kerem ERKAN
> <ker...@ha...> can confirm that.

Tomas is right, (to some point) I think there is a problem in i18n.php. We
have seen that the mail body was being decoded fine, but everything else
(these are menus, message headers, buttons etc. ONLY NOT the message body)
were being decoded wrongly. We had this problem with GNU gettext on
FreeBSD, Solaris seems not to have this problem as it does not use GNU
gettext. Solaris has a bigger flaw as it does not LIST the mailboxes
giving an error of "incorrect argument to LIST" if the language is set to
English. So none of our users can use English.

The i18n.php should include character conversion for the whole SM, not
only the message body I think.

> You need to use
> non-Turkish locale and have default_charset not equal to iso-8859-9 in
> order to see if characters are decoded correctly.
>
This part is wrong as using English locale and having default_charset =
iso-8859-1 the same problem was encountered.

> Plus I think that
>
> if (strtolower($default_charset) == 'name of charset')
>  return $string;
>
> cycles used in most decode_charset functions are not correct.
>
> If we have system that has default_charset=iso-8859-x1, user that has
> locale with charset=iso-8859-x2 and email with charset=iso-8859-x1,
> then email message is not decoded and user sees incorrect characters.
>
This part is also true. Using iso-8859-1 as default and showing a
iso-8859-9 charactersetted email, the Turkish characters don't seem
correct.

Regards,

Kerem