| Summary | On FreeBSD (at least 7.x) the charset detection fails |
| Queue | Horde Base |
| Queue Version | Git master |
| Type | Bug |
| State | No Feedback |
| Priority | 1. Low |
| Owners | |
| Requester | bra (at) fsn (dot) hu |
| Created | 12/01/2008 (6183 days ago) |
| Due | |
| Updated | 04/03/2013 (4599 days ago) |
| Assigned | 02/04/2013 (4657 days ago) |
| Resolved | 04/03/2013 (4599 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
Version ⇒ Git master
Taken from
State ⇒ Feedback
Milestone ⇒
charsets for Content-Type email headers.
Taken from Jan Schneider
Priority ⇒ 1. Low
Milestone ⇒ 3.3.2
Version ⇒ 3.3
Queue ⇒ Horde Base
from vanilla nls.php.dist.
We have to use the same charsets everywhere else in nls.php.dist.
State ⇒ Assigned
Version ⇒ 1.2
Queue ⇒ Horde Groupware
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Queue ⇒ Horde Framework Packages
Summary ⇒ On FreeBSD (at least 7.x) the charset detection fails
Type ⇒ Bug
For example my locale (Hungary, hu_HU) specifies the charset
"ISO8859-2", but when I try to compose(.php) an e-mail, it has no
charset selected, so the e-mail will have the default (the first,
Arabic, Windows-1256).
Printing in the foreach in compose.php, it seems that the loop
compares ISO8859-2 with (among others) ISO-8859-2.
So I think it would be good to have that dash, at least for FreeBSD in
nls.php.