Changes have been made in CVS for this ticket:

Pass correct charset to NLS::convertCharset() (Bug #9503).
http://cvs.horde.org/diff.php/imp/config/prefs.php.dist?rt=horde&r1=1.216.4.38&r2=1.216.4.39&ty=u

Using

$_prefs['drafts_folder'] = array(
     // The mailbox value must be encoded in the UTF7-IMAP charset (see RFC
     // 3501 [5.1.3]).
     'value' => String::convertCharset(_("Drafts"), NLS::getCharset(), 
'UTF7-IMAP'),
     'locked' => false,
     'shared' => false,
     'type' => 'implicit');

works fine as NLS::getCharset().

I admit I don't know if our translation engine always translates to 
NLS::getCharset(). If it does than that sounds like the correct 
solution.

The first charset parameter is not supposed to be empty. Try passing 
NLS::getCharset() instead.

I applied the patch from CVS to imp-4.3.9 but it does not successfully 
solve the problem.

The String "Entwürfe" is now correctly returned from the translation.

The call

String::convertCharset(_("Drafts"), null, 'UTF7-IMAP')

in imp/config/prefs.php however converts that to "Entw&AMMAvA-rfe".

An explicit

String::convertCharset(_("Drafts"), 'UTF8', 'UTF7-IMAP')

results in the correct value "Entw&APw-rfe".

The origin of that problem seems to be that the $from = null setting 
for String::convertCharset leads to mb_convert_encoding() assuming the 
origin charset to be equivalent to mb_internal_encoding(). This is 
"ISO-8859-1" however while the original "Entwürfe" string was provided 
in "UTF8".

Now I wonder if that is a local problem of the Kolab installation or 
whether this needs fixing in the Horde code. Thanks!

The UTF-7 in the translation was from before we added the 
convertCharset() call to prefs.php. But it looks like I was the only 
translator that took care of using the correct charset in that 
context, that's why the conversion was added.
Anyway, fixed in CVS and Git where it ended up with an automatic merge.

Changes have been made in Git for this ticket:

Fix Drafts translation (Bug #9503).

http://git.horde.org/horde-git/-/commit/3a1b96d373c7da9932d3fc8ef6bccfcd31c56a02

Ah, that is of course the other alternative.

Given that our prefs.php.dist in git does suggest to use the UTF7-IMAP 
conversion only in case the folder name contains non-ascii characters 
I assumed the UTF7-IMAP conversion in CVS was unnecessary. In git we 
also have a similar translation in imp/locale/de/LC_MESSAGES/imp.po:

#: lib/IMP.php:473
msgid "Drafts"
msgstr "Entw&APw-rfe"

But looking at the code there it seems as this just relates to the 
display of the folder names.

The correct translation for "Drafts" in German is "Entwürfe" and I 
assume that is all that needs fixing then. Jan, do you agree?

That translation looks incorrect.  The translation should be for the 
word "Drafts".  IMAP encoding is done on the translated word.   
"Drafts" should not be IMAP-encoded in the translation.

imp-4.3.9 has the following section in config/prefs.php.dist:

$_prefs['drafts_folder'] = array(
     // The mailbox value must be encoded in the UTF7-IMAP charset (see RFC
     // 3501 [5.1.3]).
     'value' => String::convertCharset(_("Drafts"), null, 'UTF7-IMAP'),
     'locked' => false,
     'shared' => false,
     'type' => 'implicit');

At the same time the po/de_DE.po file translates the "Drafts" string 
to "Entw&APw-rfe":

#: config/prefs.php.dist:304
msgid "Drafts"
msgstr "Entw&APw-rfe"

This way imp-4.3.9 creates a draft folder named "Entw&APw-rfe" (UTF-8) 
by default. From the current code in git I assume the encoding in 
prefs.php.dist is unnecessary. Suggested patch attached.

Original report: https://issues.kolab.org/issue4690 [kolab/issue4690 
(Umlaut problems in system folders)]