TRANSLATION extension to the NAMESPACE response supported?

Michael M Slusarz slusarz at
Wed Jul 16 07:12:24 UTC 2014

Quoting Stephan Bosch <stephan at>:

> On 7/15/2014 11:24 PM, Michael M Slusarz wrote:
>> Quoting Stephan Bosch <stephan at>:
>>> On 7/15/2014 10:47 PM, A. Schulze wrote:
>>>> Hello,
>>>> I would like to ask if the TRANSLATION extension to the NAMESPACE
>>>> response
>>>> is supported by dovecot.
>>>> context:
>>> Afaict, Oracle currently has the only implementation of the LANGUAGE
>>> capability:
>>> I haven't seen any plans for it in Dovecot so far and I think you are
>>> one of the first to request it. :)
>> This is not the LANGUAGE extension - this is namespace translations
>> (I18NLEVEL=1).
>> Dovecot has supported this since 1.1 according to that page.
> What gives you that idea? From
> The LANGUAGE extension allows the client to request a suitable  
> language for protocol error messages and in combination with the  
> NAMESPACE extension [RFC2342 <>]  
> enables namespace translations.

My mistake.

I implemented this long ago, and I explicitly remember parsing the  
extended namespace translation data.  I assume this testing was done  
against a Dovecot server.  However, a look at the code indicates that  
the testing was from static data in our unit tests.  Whoops.  I stand  
corrected.  This is part of LANGUAGE rather than I18NLEVEL=1.

LANGUAGE is pretty much worthless other than the namespace part ...  
who cares if the human-readable text is translated since, other than  
ALERT text, it is never shown to the end-user?  That explains why  
nobody has implemented it.


More information about the dovecot mailing list