Hi, It's funny about multilanguage in DSpace. After a lot of changes in source code, I've made it work quite well but the default.license issue. When you edit the license in the administration interface, it shows the correct one, that is, the one according to the user's preferred language. And if a user completes a submission, then the license is showed, not in the preferred language of the user, but in the (apparently) last language showed in the edit license. As an example, if an administrator edit the license for spanish language and then a standard user starts a submission in its preferred language (english, for example) then the license is not showed in english, but in spanish!!!
I've studied all the source code involved in this issue: [dspace-src]/dspace-api/src/main/java/org/dspace/core/ConfigurationManager.java [dspace-src]/dspace-jspui/dspace-jspui-api/src/main/java/org/dspace/app/webui/servlet/admin/LicenseEditServlet.java [dspace-src]/dspace-api/src/main/java/org/dspace/core/I18nUtil.java but apparently everything is OK. Regards, > Message: 3 > Date: Mon, 3 Oct 2011 15:15:19 +0200 > From: Christian Voelker<c.voel...@gmx.net> > Subject: [Dspace-tech] Several concurrent Localizations of > default.license, input-forms etc. dont work > To: listaDspace Tech<dspace-tech@lists.sourceforge.net> > Message-ID:<1e49e23f-e958-4dc1-b11c-00a3c6bdb...@gmx.net> > Content-Type: text/plain; charset=windows-1252 > > Hello, > > you know what I am dealing with recently. Localization in DSpace 1.7.2. > > I tried this thoroughly in every way I could think about: > > <https://wiki.duraspace.org/display/DSDOC/Configuration> > > It reads like this: > >> Supporting More Than One Language >> >> Changes in dspace.cfg >> >> Property: webui.supported.locale >> Example Value: webui.supported.locale = en, de >> (?) >> >> Related Files >> >> If you set webui.supported.locales make sure that all the related additional >> files for each language are available. LOCALE should correspond to the >> locale set in webui.supported.locales, e. g.: for webui.supported.locales = >> en, de, fr, there should be: >> >> (?) >> Files to be localized: >> (?) ? [dspace-source]/dspace/config/input-forms_LOCALE.xml >> ? [dspace-source]/dspace/config/default_LOCALE.license - should be pure >> ASCII >> (?) >> ? [dspace-source]/dspace/config/emails/change_password_LOCALE >> ? [dspace-source]/dspace/config/emails/feedback_LOCALE >> ? [dspace-source]/dspace/config/emails/internal_error_LOCALE >> ? [dspace-source]/dspace/config/emails/register_LOCALE >> ? [dspace-source]/dspace/config/emails/submit_archive_LOCALE >> ? [dspace-source]/dspace/config/emails/submit_reject_LOCALE >> ? [dspace-source]/dspace/config/emails/submit_task_LOCALE >> ? [dspace-source]/dspace/config/emails/subscription_LOCALE >> ? [dspace-source]/dspace/config/emails/suggest_LOCALE > This does not work (TM) in XMLUI. > > I also tried to constrain language support explicitly for XMLUI using > xmlui.supported.locales = en, de > > LICENSE > The only license file displayed as deposit license is default.license. > Hint: If somebody wants to take on the task to fix it, he or she might > think about finding a more meaningful name such as required.license > or deposit_license. > > INPUT-FORMS > A localized file such as input-forms_de.xml does not get used either. > > EMAILS > Localized emails dont get used. This was the same back in DSpace 1.4 > when we used JSPUI. It does not work if you leave the english version > as e.g. change_password and add a file change_password_de. > > It does not work if you move change_password to change_password_en and > add a file change_password_de resulting in a emails template folder > where there is no fallback change_password file left. Even then, the > change_password_en gets used with a browse set to either de-DE or en-US! > > You can even have change_password be the german version and have the > original change_password file moved to change_password_en. The fallback > change_password without locale appended gets ignored with browser > setting being either de-DE or en-US. Only the change_password_en > gets used. > > I guess, the locale is not set for email at all. My whole server > machines default locale is de_DE.UTF-8. It looks as if still, the > locale is assumed to be en for emails so that always the _en version > is closest match an cant ever be overruled. This wont become obvious > to anybody using en as his or her default locale. > > > I could not judge which these three things is most annoying. License > tend to be read with each word carefully evaluated. We dont have an > english version of our deposit license. So I can live with replacing > the default.license completely. > With emails, form mails are prone to being filtered as spam anyway > and english form mails are scoring higher in spam filters. But as > long as I dont shut english as an interface language, users should > get their mails in their respective language. It is especially > disappointing that this has not been fixed in years. I remind that > I had reported this already about three years ago. > The input-forms file is also very important because there might be > domain specific alterations of verbiage which might leed to mis- > conception as of what is shown to the visitor. > > Bye, Christian ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
