TRANSLATION extension to the NAMESPACE response supported?

[Michael M Slusarz]

Quoting Stephan Bosch <stephan at rename-it.nl>:

> On 7/15/2014 11:24 PM, Michael M Slusarz wrote:
>> Quoting Stephan Bosch <stephan at rename-it.nl>:
>>
>>> 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:
>>>> http://lists.horde.org/archives/horde/Week-of-Mon-20140714/052136.html
>>>
>>> Afaict, Oracle currently has the only implementation of the LANGUAGE
>>> capability:
>>>
>>> http://www.imapwiki.org/Specs
>>>
>>> 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 http://tools.ietf.org/html/rfc5255#section-1:
>
> The LANGUAGE extension allows the client to request a suitable  
> language for protocol error messages and in combination with the  
> NAMESPACE extension [RFC2342 <http://tools.ietf.org/html/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.

michael