I stumbled upon a not very intuitive behaviour. In order to be able to enter texts like about the journal or journal description in more than one language, that locale’s “forms” checkbox has to be checked. While the backend offers forms indeed I find this quite counterintuitive since texts entered by the editorial staff could also be seen as part of the GUI. Offering a local solely for GUI purposes is being rendered pointless by that behaviour in my opinion.
Yes, that behavior is intentional. For many journals, I suspect the multilingual data is a level of complexity they don’t want to tackle – despite potentially wanting to present the user interface in a couple of languages. And we wouldn’t want to tie the choice of UI languages to the choice of form languages on a 1:1 basis.
Regards,
Alec Smecher
Public Knowledge Project Team
I assume though that it is more complex the way you set it up now. In order for a journal to offer the user interface in more than one language (and that does include guidelines for example) the additional language has to be activated for forms as well. By doing that, visitos will have access as well to bi- or multilingual forms. And it would be possible as well to just fall back to the default language if there is no translation available.
OJS always falls back to the primary language when a piece of data isn’t available in translation. Imagine a journal that wants 3 languages available for the OJS UI, but doesn’t want to triple the number of form fields. Conversely, we’ll probably have to further expand language options to support journals that need metadata in languages that the OJS UI doesn’t support – for example, First Nations languages here in Canada. I know it seems strange, but the UI languages and the form languages need to support a different locale set for each. (And for that matter, the submission locales.)
Regards,
Alec Smecher
Public Knowledge Project Team
Let’s say I want to offer readers a bilingual GUI. In that case I have to activate the second localization for forms as well in order to be able to translate i.e. the “additional content” field. But by activating it for forms, all forms are bilingual. In my opinion general backend texts like “additional content” or “about the journal” are closer to GUI content than regular forms. I found it very confusing being forced to activate a localization for forms as well in order to offer bilingual description texts and it actually lead to quite some cursing …
Are you proposing to change the options on the forum, or the labeling of the controls, or something else? I’d be happy to improve this if we can make it clearer, just not at the cost of forcing the set of UI languages and the set of form languages to be the same.
Regards,
Alec Smecher
Public Knowledge Project Team
I suggest not handling texts belonging to the journal itself (like journal description, about us and so on) and not to a specific issue or user as part of forms but as gui texts. If a journal wants to offer a multilingual gui we can assume that they usually want to offer their descirptions in different languages. Since you already mentioned that OJS falls back to texts specified for primary locale, journals with multilingual gui but no interest in multilingual description texts could just ignore it. I think this way it’s less confusing and it wouldn’t take journals to actually activate a locale for forms even though the intent was just to offer multilingual description texts.
I suspect that journals not currently configured to use multilingual inputs would be confused by their sudden appearance – but frankly UI/UX is not my strong point. @stranack, do you have an opinion?
Regards,
Alec Smecher
Public Knowledge Project Team
