The general workflow in OJS is to define a “default” language locale, and fill data from that into any alternate language locale that is missing translated data.
This is problematic when a user is not familiar with the primary locale, but is fluent in one or more of the alternate locales.
I don’t think always requiring multilingual entry is a general solution. With users, for example, a journal manager might want to allow the entry of name variations in any relevant language, but it is unlikely someone would be able to perform the entry in all possible languages.
I could imagine a journal wanting to curate robust translations for a bilingual journal and perhaps having the option to require dual language entry. That probably goes beyond the use case of just name entry, however. Requiring dual language entry would probably be a system-wide setting at that point.
I might really miss something. So I’m ready to agree that the journal manager should have an option to either require dual language entry (for names and other fields in multilingual journals) or not.
E.g., in Russia it is really a prevalent practice: if you submit a paper, you must provide 1) your latinized name; 2) title in English; 3) abstract in English; 4) English keywords. Most often it is a necessary condition for paper submission and acceptance.
But as far as I can see, all those required fields are ‘hardcoded’ in OJS3. We cannot set which field is actually required and which is not. I believe, many of us would find such functionality really important.
I now that my hack isn’t ideal but I hope it will work. Now I test how it works on http://vestnik06.susu.ru
Our journals use two languages: English and Russian.
as I’m interested in all parts of i18n just a few thoughts. Transliteration and Transcription depends always on set of rules which might differ locally (ISO, DIN cataloguing rules etc.) and over time. Here is an Example from VIAF (Virtual International Authority File)
So if a mechanism is implemented, the rules must be part of it and one should be prepared for changing rules.
But the first step is unambiguous identification (authority control) of the author. Even an author himself might enter different names from one submission to the other.
There we could rely more on ORCID.
ORCID allows the author to add additional name forms, but these are not qualified or controlled.
As to adding additional name forms, this is important too. But I think it is what @ctgraham meant here: [quote=“ctgraham, post:27, topic:13157”]
Authors and reviewers would be able to add a “published name”
[/quote]
We are definitely interested in leveraging ORCID as the standard for author name disambiguation.
With regard to transliteration of names, we are planning on putting the weight of this on the authors and/or editors, rather than depending on an external Authority source.
User “Manoj Shyamalan” might elect to add a published-as name of “M. Night Shyamalan”, and might clarify for APA citation purposes that he wanted the name to appear as “Shyamalan, M.” if the default was “Shyamalan, M. N.”.
This has not been officially scheduled. I would anticipate this being added to the Pitt ULS’s development priorities for 2017, but don’t have a real timeline.
This is not currently scheduled. One of the next steps is enable longer locale names · Issue #1911 · pkp/pkp-lib · GitHub where we introduce script variants into locales. The differences of script variants will be one of the distinguishing characteristics of internationalized names.
The above issue is to allow encoding to be specified as part of the locale name, permitting the same language to be used in multiple encodings (e.g. Serbian in both Latin and Cyrillic). That was merged and will be included in OJS 3.1.
As for multilingual author names, this is still a priority for us and will be addressed in a future release. It hasn’t been scheduled specifically yet, however.
Regards,
Alec Smecher
Public Knowledge Project Team
OJS 3 is not suitable at all for journals that publish articles in two languages. What are the technical arguments that do not provide a possibility to input in metadata the author’s name and References in the second language? Just do in the same way as title, affiliation etc.
@Vitaliy I like your solution using subdomains as a language prefix for multi-language OJS sites.
Probably, it would be good to have some sort of relation visible between the article landing pages across the language subdomains. There does not appear to be a standardized link relation for translations, however.
Do you have a public OJS site where this is already rolled out and you could see the result of this change in terms of Google Scholar indexing?
I had made appropriate modifications of google scholar and DC plugin only a few days ago. So, need to wait several weeks to see the changes in indexing. For now, 2 languages are indexed only in Google.
Our site:
but I hope it will work. Now I test how it works on