<stream> language attribute not used. No multilanguage in XMPP streams

I have found that Openfire sends several responses as human readable throught the XMPP stream in the same language as the Openfire server is configured with. But in the opening <stream> tag of a XMPP stream, the client could specify a language to denote the language of the human readable messages sended to the server.

I think Openfire server must use this language (of the opening stream tag), to set it as the language for the response stream, and send the responses of the server on the same language as the connecting client.

An example of this is the following:

  1. I open a new account with the openfire server.

  2. My client sends a language of ‘en’ in the openning stream tag, and my openfire server is configured in Spanish.

  3. I register a MSN account in the Gateway plugin, but the password is wrong.

  4. The Gateway plugin sends a <message> stanza to the client with a text notifing the client that the password is wrong, but that message is in Spanish language, the same as the server, but not in the language of the client.

I have been looking into the openfire 3.3.3 code and I found that on class “LocaleUtils”, method “getLocalizedString(String, String,List)”, the only language taken in care is the Openfire configured language.

What do you think about this?

I have modified an Openfire 3.3.3 version, and added a new parameter to Localeutils.getLocalizedString(String, String, List), the session user JID (not the bare JID) in where the string must be retrieved. for values of the JID of null, it return the string in the configured language of the openfire server (useful for web pages), and if the JID is not null, it used the language of the session connection for that user. It works, and now I receive human readable responses in the same language as the client language.

I only have taken me about 3 hours.

Do you think this could be a new Bug or requirement for the Openfire Server?

I can send you my modifications if you need them.

Thanks for the patch!! See JM-1174 =)

This functionality is something we (James Bunton and myself) adopted in the Py* transports, and was often well regarded. Judging from your patch it looks pretty simple to implement too.

Hello, Where did this patch go? The Jira ticket OF-208 is misisng it as well…