I have a multilingual journal and have a question about the “language” filed of an article.
When submitting a new article there are two language fields:
Step 1, under Submission Language (This journal accepts submissions in several languages. Choose the primary language of the submission from the pulldown below.)
Step 3, under Indexing
What is the difference between the two language fields? Especially the first one confuses me. What are their purposes?
This is mostly a legacy issue. Originally only the language field under Step 3 was present, and that corresponds to the Dublin Core language field. A few years ago we added some new functionality to OJS to better facilitate multi-language journals, resulting in the addition (among other things) of the language chooser on Step 1.
The Step 1 field pre-populates the Step 3 field, and it’s the Step 3 field that’s mostly used e.g. when presenting metadata to external systems that consume Dublin Core or similar.
Regards,
Alec Smecher
Public Knowledge Project Team
Thank you for the answer. I was expecting something like this.
However, there is one thing I don’t like with the new approach and I have to let you know. I have a multi-languge journal that issues articles in several languages, also in some that are “officially” not supported. Let me explain it a bit more:
The OJS installation supports only English and Slovenian. All metadata has to be provided in English and Slovene, UI is used only English and Slovenian.
Actual articles (PDFs) can be in many other language, that are not supported by OJS at all (and I guess will never be), e.g. Ukrainian, Belarusian,…)
If I got it correctly that means that unsupported languages can not be selected in the step 1, right? So with the new approach (language filed in the step 1) you can not specify the article attributes (language) correctly, you are able to do it only with the old legacy filed (step 3).
My point is that it is not good approach to limit the language attribute of an article only to the set of languages that are supported by the OJS (step 1). My opinion is that it is much wiser to live it open and use only filed in the step 3.
I think a good solution that still permits some of the “smart” elements the drop-down language standard permits is to allow the drop-down to include some languages that aren’t necessarily translated in the system.
Regards,
Alec Smecher
Public Knowledge Project Team
Although I agreed with you on this topic, now I found out we should consider this issue a bug. The problem is that while uploading a PDF file you can choose language for the PDF only from the list “Submission languages” (step 1 above). That means you can not publish PDF in other languages then supported by the OJS. And supported means UI is localized in that language as well.
Considering the explanation above, I would suggest not to limit the languages of PDF to the OJS supported languages only. It should be open to all languages, like for the indexing purposes (step 3 above).
I have to say I expect to have some problems because of that on one of my publications that is dealing with Slavic languages.
I can see a valid argument for both approaches – it might be best done as a local modification on your side. See classes/submission/form/ArticleGalleyForm.inc.php in the constructor function: