Translations into Russian

Translations into Russian

Translations into Russian

Translations into Russian

Translations into Russian

Translations into Russian

Translations into Russian.

Translations into Russian

Translations into Russian

Translation into Russian

* Full translation into Russian.

I completed the translation into Russian. My profile on discourse.igniterealtime.org - IvanRussian

* Update openfire_i18n_ru_RU.properties

I'm finished for today, but will continue to edit next weeks

* OF-1448: Encode UTF-8 i18n files during build.

* OF-1448: Keep non-encoded i18n files in source.

* OF-1450: Replaced hardcoded text with i18n-property in logviewer.

* OF-1450: Replaced hardcoded text with i18n-property in email settings.

* OF-1450: Replaced hardcoded text with i18n-property in TLS/SSL menu.

* OF-1450: Replaced hardcoded text with i18n-property in test email settings.

This commit aims to make the Maven structure more compatible with Sonatypes guidelines for artifact distribution, as defined on http://central.sonatype.org/pages/ossrh-guide.html

A new Maven profile 'release' is added, that intends to produce all required artifacts. Usage: mvn -P release clean verify

This is an attempt to workaround an issue introduced whereby the database schema version is incorrect.  More info is here
https://discourse.igniterealtime.org/t/79916

The mysql change worked for me on mariadb 5.5.56

Denote Openfire 4.2.0 Release

* OF-1444: Ensure that mvn packaged log4j.xml file does not have the variables expanded

* OF-1444: Don't set the default option

* Fixed ofGojaraSessions missing after install

* Bump patch version

* update gojara changelog

fixes commit c44f29 from PR #931

Oracle and IBM JREs appear to provide 'java' properly, whilst not java-headless

OF-1438: Add method to replace an entry in the identity store.

OF-1373: Wait until file modifications are complete.

OF-546: Exclude MINA bundles

The logic here was wrong, but trying to handle SCRAM when we
could read the password, or there was native support. However,
the existing SCRAM code doesn't perform any fallback - instead
that's left to the AuthProviders themselves to implement.

So the new logic just assumes that an AuthProvider which can
provide that fallback will advertise it. If we later make this
support generic, it can go into the AuthFactory level.