[OJS 2.4.8] Languages supported locales but not as UI for main page

Software Support
1

I have an OJS with several journals for which people turn in articles in German, English, Spanish, French and Italian. But our OJS only (should) support German and English as UI.

To differentiate the languages of the articles/galleys I have to check all the languages in “User / Site Administration / Languages” and then I uncheck all languages but German and English as UI in e.g. “index.php/JOURNAL/manager/languages”, so that all five languages are only checked for Submissions.

This workflow works pretty fine unless you are on the main page where all journals are listed, there you can switch the UI to all five languages (which I dont want).
So, is there a possibility to have only German and English as UI-language even on the main page?

2

Hi @lcbossert,

Hmm, that’s not a particularly common requirement – at least I haven’t heard it before. For expedience, I’d suggest perhaps making a local modification to the front end language switcher markup. This is implemented in plugins/blocks/languageToggle/block.tpl. If you think you end up with a generally useful function that doesn’t add complexity for the majority of users who won’t need it, consider sending back a pull request.

Regards,
Alec Smecher
Public Knowledge Project Team

3

I suspect a good and simple solution would be to modify the population of $languageToggleLocales to be the union of all distinct journal UI values.

(instead of line 90 here).

4

Hi @Alec and @ctgraham ,

thanks for the feedback and the possible solution @ctgraham . I will ask our IT-guy to work that out.

Just a question: wouldnt make it sense to have also checkboxes for UI for the main languages (including the option “all” / “none”) so every admin could freely choose the UI-language?

5

There is a disconnect between the language enabling interface at the site level and at the journal level. Adding explicit checkboxes for the site UI would clarify that, but would also be a seldom used distinction. If you wanted to look into that instead, compare:
Admin languages handler
and
Admin languages template

against

Journal languages handler
and
Journal languages template

That feels like more effort than value (for the legacy version) to me, however. I wondered if one of our journal installs might benefit from this change, so I coded out a possible solution of:

diff --git a/plugins/blocks/languageToggle/LanguageToggleBlockPlugin.inc.php b/plugins/blocks/languageToggle/LanguageToggleBlockPlugin.inc.php
index d35f888..f1bd3d6 100644
--- a/plugins/blocks/languageToggle/LanguageToggleBlockPlugin.inc.php
+++ b/plugins/blocks/languageToggle/LanguageToggleBlockPlugin.inc.php
@@ -86,8 +86,18 @@ class LanguageToggleBlockPlugin extends BlockPlugin {
                                $locales =& $journal->getSupportedLocaleNames();
 
                        } else {
-                               $site =& Request::getSite();
-                               $locales =& $site->getSupportedLocaleNames();
+                                $site =& Request::getSite();
+                                $siteLocales =& $site->getSupportedLocaleNames();
+                                $journalDao =& DAORegistry::getDAO('JournalDAO');
+                                $journals =& $journalDao->getJournals(true);
+                                $locales = array();
+                                foreach ($journals->toArray() as $journal) {
+                                        $journalLocales =& $journal->getSupportedLocaleNames();
+                                        $locales = array_merge($locales, $journalLocales);
+                                }
+                                if (count($locales) == 0) {
+                                        $locales = $siteLocales;
+                                }
                        }
                } else {
                        $locales =& AppLocale::getAllLocales();

I got distracted by another bug I found before fully testing it.