Quoting Stephan Bosch <[email protected]>:
On 7/15/2014 11:24 PM, Michael M Slusarz wrote:
Quoting Stephan Bosch <[email protected]>:
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
