pkp/pkp-lib#7272 Simultaneously Displaying Multilingual Metadata on the Article Landing Page #4050
Conversation
|
Hey @asmecher, I have PRs ready for review of the code... OJS: #4050 |
|
Thanks, @jyhein! I'd like to start by passing this by @Devika008; can you add a couple of screenshots that show the changes? |
asmecher
changed the title
asmecher
changed the title
|
Hey @Devika008 and @asmecher, Here are some screenshots:
|
jyhein
force-pushed
the
f7272
branch
3 times, most recently
from
31520dd
to
f37b2a0
Compare
|
I'm sorry for getting onto this late. I might have missed it. However, I believe that when users read through the data, they wont read data in a way that article title in french in Spanish in Portuguese and then move onto the next one. They will go through the metadata together in a language. Sometimes its easier to scout for metadata when you know the language you're looking for. Hence I propose the following reorder of data with respect to clubbing the metadata in one language togehter. Its easier to process and find
|
jyhein
force-pushed
the
f7272
branch
3 times, most recently
from
5d41251
to
a7ddb59
Compare
pages/article/ArticleHandler.php
Outdated
| ->concat(['keywords', 'abstract'])->unique()->diff($titles->keys())->values(); | ||
| $multilingualOpts = collect($showMultilingualMetadataOpts) | ||
| ->when(in_array('title', $showMultilingualMetadataOpts), fn ($m) => $m->concat(['subtitle', 'fullTitle'])->unique()->values()); | ||
| $primaryLocale = isset($titles->get('title')[$contextPrimaryLocale]) ? $contextPrimaryLocale : $publication->getData('locale'); |
There was a problem hiding this comment.
I think this is not correct: why do we use the context primary locale?
See how the function DataObject::getLocalePrecedence() works (https://github.com/pkp/pkp-lib/blob/main/classes/core/DataObject.php#L97), used in DataObject::getLocalizedData() (https://github.com/pkp/pkp-lib/blob/main/classes/core/DataObject.php#L65):
First either preferred locale will be considered, if given (e.g. if you want to get a key/attribute in a specific locale).
If preferred locale is null, the UI locale is considered.
If there is no value for this locale, then the fallback locale (getDefaultLocale()) is considered. For Publication object it is the submission primary locale (s. e.g. PKPPublication::getDefaultLocale()). This value should actually always exist for required fields.
And if no value is found here, e.g. for keywords that do not necessarily need to be in the submission primary locale, then check context and then site primary locale.
If no value exists for any of these locale the function getLacalizedData() will return the first found value.
Thus, I think we should do the same here, no? Also, if possible to use that getLacalizedData() function.
Also, on the article view page:
With this implementation the context primary locale instead of UI locale (that exists) is displayed. For example, let say context primary locale is FR, and the article primary locale is EN, and metadata exist in both languages (EN and FR). When the UI locale is EN, the article is displayed in FR, although EN exist.
If the UI would be DE, and article does not have metadata in DE, the EN should be displayed, because EN is the submission primary locale.
I do not know if Devika said something about the situation when e.d. keywords only exist also in DE, additionally to the example above.
Currently it is so: if the UI = DE, then title and abstract are displayed in EN (because they do not exist in DE, but in submission primary locale), but keywords are displayed in DE.
I think for now we should keep this, if Devika has said nothing about it now, how it woks now. And I think Devika wanted to think further about how to improve it all...
What do you think?
There was a problem hiding this comment.
I changed context->getPrimaryLocale() to templateMgr->getTemplateVars('currentLocale'). If no "show multilingual metadata" options selected in the default theme settings and metadata does not exist in title's locale, then the metadata is shown in some other language.
There was a problem hiding this comment.
Hi @jyhein, I have not taken a look into the code yet, but I tested it, and there is still some difference from how it was till now:
Lets say the journal has EN, FR, DE, and SP enabled as UI and submission languages.
Lets say the article primary locale is EN, and it has all metadata also in FR, and additionally it also has author metadata and keywords in SP.
When the reader select SP as UI language:
Now it is so:
The article title and abstract are displayed in EN, author metadata in SP, and the keywords also in EN, although the keywords in SP exist. Then the article metadata in SP are considered next, and there the keywords in SP are displayed.
If the new option to show metadata in all languages is not selected in Website Settings, then the SP keywords are never displayed.
Thus, I think it should be:
The article title and abstract are displayed in EN, author metadata and keywords in SP. Then the other languages are considered the data exists for, i.e. EN and FR.
Thus, could we do something like this:
For the first/main display of metadata use getLocalizedData as till now. This first/main display considers the selected UI language. It will return either the data in the UI language or the data in article primary language or any other existing language.
Then for the new functionality, to display metadata in further languages: Get all existing article languages for the selected metadata from the settings (title, abstract, keywords), remove the UI language from that list (because it is handled as first), then for each language from that list display existing metadata using getLocalizedData(key, language).
I am not 100% sure, but maybe in the handler class you would 'only' need to get those further languages that needs to be displayed (= get all existing article languages for the selected metadata from the settings (title, abstract, keywords), remove the UI language from that list). And then in the template this can be done: for each language from that list use getLocalizedData(key, language) to display metadata in additional languages.
There was a problem hiding this comment.
Hey @bozana! Default view (no metadata options selected): the code tries to give the metadata based on the title language (if not ui then submission). If the metadata does not exist in title language, then the getLocalized data selects some found language. I tried to avoid to display a mix of languages as much as possible. I can change this to match the original logic, or I could display the other languages the same way like in the multilingual view.
Multilingual view (one or more options selected) : Using getLocalizedData won't work here because if in UI/submission language e.g. keywords do not exist, the function would show it in other language. In this view it would be inconsistent.
I have not included author metadata in to this but I can do that
There was a problem hiding this comment.
Hi @jyhein, I am hesitant to change how it worked till now -- it was so for a long time... :-) Also because maybe not all users will use this additional function and the system should behave as always. The keywords in SP from the example above should be visible. (Also, users could extend the default theme to also display other metadata (e.g. coverage, sponsoring agencies, etc.) and they would probably follow the same logic, and they all should be visible in default view).
And because Devika will maybe come with a fully different model/logic later... So lets keep this as it was, for now, i.e. with minimal changes, if possible.
Thus, I think default view (no metadata options selected) should work as till now.
The multilingual view (one or more options selected): the first metadata display should stay as it is, as in the default view, and only the other existing languages (different than selected UI language) should be added.
Sorry, I was wrong about getLocalizedData for additional (other than selected UI) languages: it should be getData(key, locale)....
You do not need to include author metadata -- it was just an example, that they can also be in other languages, i.e. in SP in the example above and would be visible...
jyhein
force-pushed
the
f7272
branch
3 times, most recently
from
f95676a
to
0baa986
Compare
|
Hi @Devika008, Article Metadata in EN Article Metadata in FR That means under "Article Metadata in EN" the title and abstract will be shown, even they are also shown in the first element (for UI = SP) because they do not exist in SP. Else, @jyhein, tried not to mix the languages, so that way it now would be: Article Metadata in SP Article Metadata in FR This looks maybe OK when the option to show the metadata in multiple languages is selected, but when that option is not selected, the SP metadata will never be displayed, which I think is not a solution. Also, this changes the way how it was till now. Thus, just to double check with you what do you think is better for now, and to let you know about this edge case when you work on the default theme further. Thanks a lot! EDIT: I think we could also consider authors metadata in the #2, so that not only they are displayed in UI=SP in the first element, and we could maybe differentiate the situation when the option to show the metadata in multiple languages is selected or not (so that the SP data are shown if that option is not selected), but it is all even a bigger complication. |
|
@Devika008, maybe just a note: I have just spoken with @jyhein and we will then try to have separate solutions for those that have the multilingual view enabled and those that do not have it (which will work as till now). @jyhein will document it in the issue on Monday... I still think that we are maybe investing too much time now, because we will need to rethink it all soon (when submission and metadata languages are separated from the UI languages), and eventually when UI language will be accessible via URL... but... |
jyhein
force-pushed
the
f7272
branch
2 times, most recently
from
4b735dc
to
aed56ac
Compare
|
Hey, @Devika008 Here are some some cases when metadata exist partially only:
Case 1: Only keywords in Swedish:
Case 2: Only title in Swedish
|
|
@bozana I think your examples show that the real problem we have in OJS (and which is underlined now more) is the concept of mixing metadata based on the UI language. I mean this:
This is confusing for the reader especially in cases where the two languages are close to eachother.
I do not think that having the UI language accessible via URL will affect this. It will just change the way language switching is happening. The real question is that should the UI language affect submission metadata view especially in cases where the full metadata is not available for the selected language. In my opinion such functionality should only happen when the full text is multilingual and in all other cases we should always respect the Submission Locale. But I think this issue is separate from that. The real use case for this is a situation where only small parts of metadata (like the abstract) is available in other language and the editors want to show that on the same landing page. IMO we should not try to extend this further from that concept. |
|
@ajnyga, yes... So what do you think is best for this issue, now? EDIT: because according to the design, we do not display the abstracts one after another (which would be much easier), but first all metadata in one language and then in other, and then other,... (for all existing metadata languages)... EDIT EDIT: I am not thinking about the way we will solve the UI, submission and metadata languages and URL languages now -- we will wait for Devika's concept... |
|
Hi all, I believe this could be maybe the next issue we can finish :-)
If the journal has additionally FR as submission and metadata locale, and FI as metadata locale. How would those be considered/displayed, if the article has all data in FR and some metadata in FI? Thanks a lot! |
Just want to underline two things:
|
jyhein
force-pushed
the
f7272
branch
2 times, most recently
from
65fd6ac
to
7d7cde1
Compare
|
Hello @bozana @jyhein and @ajnyga, I apologize for not addressing this issue sooner. It appears that there is a problem with my GitHub notifications, as they do not send me updates when I am tagged in something. (time to correct it) Initially, this appeared to be a straightforward issue, and due to my newness in the industry, I suggested a simple solution without considering potential edge cases and complexities. However, as I began to read comments from Bozana and Antti-Jussi, it became evident that this was a more complex problem than anticipated. Over the past few days, I delved into research and reading, and I now believe that the solution is a relatively simple fix. Part 1 of the Solution: Modifying the language dropdown on our UI to display appropriate indicationsTypically, webpages and applications disrupt user experience and create confusion when there are inadequate indications. Consider it akin to entering a highway without clear signs indicating which exits are open and which are closed. By providing indicators in the language dropdown, users can ascertain which languages are complete and which are not before they proceed to change the UI. This preemptive information enables users to understand what to expect before making any adjustments. Furthermore, after extensive reading of various materials and webpages, it appears that many multilingual websites are also adopting this approach as the way forward. Below, you'll find a screenshot illustrating how the dropdown could appear. We can integrate this information by implementing code that checks for incomplete form fields when metadata is filled.
Alternatively, if implementing it in the dropdown would be confusing, an indication can appear at the top of the page when a language is selected, stating whether the translations are complete or not. We'll opt for whichever solution is easier to implement. Now, I'll outline how the information can be presented on each page.
UI: ENTitle (EN) Metadata in other languages
UI: DE
Metadata in other languages
UI: ES
Title (EN) with indication that translation not available on the side Metadata in other languages
In this case we are do not show the keywords, not because the translations are not available but because the editor / journal manager has chosen to not show keywords UI: ENTitle (EN) Metadata in other languages
UI: DE
Metadata in other languages
UI: ES
Title (EN) with indication that translation not available on the side Metadata in other languages
|
|
Hiiiii, Following our discussion in the last CRAFT OA call, I've prepared the UX/UI for this issue. I believe this solution will address most of our problems and should be relatively easy to implement. I have extracted the examples from the instances mentioned above, so I'll reiterate them here for clarity.
UI: EN UI: DE UI: ES
UI: EN UI: DE UI: ES |
|
I think this is an interesting concept with the navigation on top. To be honest my initial concept/idea was just to imitate what the journals were already doing when adding the abstract in more than one language to the same abstract field in order to show the data on the same page. This is of course more complex, but probably would serve the same purpose. What do others think? @asmecher @bozana @marcbria @AhemNason |
|
Hi Devika, I'm sorry to say that this time the proposal doesn't look good to me and I think it's all because we haven't been able to convey to you the main problem we are trying to solve (although I never rule out that I might be the one who is not clear about it). ;-) I understood that the main objective is to allow bilingual researchers to read two languages at the same time (for example because my knowledge of one language is not as good as the other and the translated text serves to clarify) but the current solution does not allow this. For example, if I want to read the abstract in English and French, I have to scroll (or click on the header) to jump from one text to the other... and nobody will do this. Fellows, if I am wrong in the definition of the feature, please correct me. That said, I also see UI/UX problems in the proposal such as:
I comment on each case: 1. Excess of informationAbout the content:
About the interface:
2. Problems with the hierarchy of information
3. Not enough emphasis on the submission language.If I put myself in the shoes of a bilingual researcher, I always want to know in which language the article was written, as there is no guarantee that the translations have been done by the authors themselves (lots of examples of errors in translations in science). 4. Switch on/off functionalityWe are working with the assumption that this is going to be a functionality that we activate at the journal level (editors/admins choose whether the article page shows all the langs or just one), but after some more thought, I think it is a mistake of approach as it is really the reader who should decide how the metadata is displayed. So why not approach it as a "reading tool" (a term familiar to the old guys in the room)? ;-) This would be an interface functionality that the reader can activate or deactivate at will (e.g. as a new icon in the header) and therefore available in all OJS. I discuss this idea in the next point. Some ideasI suggest some ideas on how the problem could be solved without making the information so overwhelming. Translations in the same field: I understand that what he is proposing is that, instead of dividing the page into languages, the languages should be interspersed in the fields, which would allow the bilingual reading I was talking about at the beginning. It will looks like something like this: https://journal.fi/virittaja/article/view/126811 The problem I find here is that if there are many translations, the volume of information will saturate the reader... and showing this way it's a decision made by the editors/admins, not by the readers. Side by side: This solution would have two drawbacks:
Nice part is:
Click to switch:
I would propose that, in the case of registered users, the language jump should be made only between the languages that the reader has indicated as "languages he/she knows", which in turn could be an incentive for visitors to register. Devika, sorry for the long feedback, but I just didn't know where to cut. Take care! |
|
Hi, I had this in the drawing board but Marc was faster :) So these comments are mostly something where I have not considered what Marc writes above. In general I would prefer a simpler solution. I do think that the addition of explaining with the "i" element why OJS is showing some random language in the top for some fields would be a good idea, but I am unsure about the two elements above title (is metadata complete for the current language and the language links). The use case here is to me not so much to show all possible content to bilingual readers. I do not think it serves them to have the same data in two languages which they are able to read. The main use case is journals that publish mostly with one language, use one UI language BUT also produce for example English metadata mostly related to abstract and title of the article. Currently in OJS if you have one UI language enabled, the metadata with other languages is not shown at all. And to solve this what journals do is that they add the metadata in several languages into a single metadata field to be able to show it online (https://journal.fi/virittaja/article/view/126811). We should have another solution for these journals they can easily use AND produce good metadata. How would we define "all metadata available" Authors field Visual elements in default theme? |
Hummm... didn't thought in this scenario. It's not a common case here.
Noooo, peeeeople, pleeease... don't do that. :___-(
Well, there are different levels of knowledge of a language. But my apologies if I was straying off topic and thank you for focussing the issue.
And what about letting the journalmanagers decide about this?
Agree on both. |
|
Firstly, thank you so much for taking the time to explain the problem in detail. I believe my faulty UX/UI solution prompted a more in-depth response, providing me with greater detail about the issue. I realise now that I was working with some wrong assumptions and lacked crucial information, so thank you once again. I reviewed both your responses in detail and have a solution in mind, which I will present here. However, I want to address some questions raised above first.
Based on the information I have received, there are two factors at play: UI language and metadata language. UI languages could be: English(EN), German(DE) and Spanish(ES) This means that even if I change the UI language to German (DE) I can still see or have access to metadata in English(EN), Spanish(ES), French(FR) and Finnish (FI) This was the example I was working on and let me know if my understanding on this particular case is correct @bozana @ajnyga and @marcbria Proposed SolutionFirstly thank you @marcbria for putting the some ideas across because just yesterday I was tinkering with something on similar lines I have been researching bilingual speakers and found that a side-by-side view works best for comparing information and filling in gaps. I believe the readers, not the journal managers, should decide on this format, as they are the ones using the data.So here is my solution. I made a very very very very very basic drawing (scribble) but only if you'll agree with the proposed solution, ill go create a mock-up 
Some Guiding Questions for this proposal over and above the questions and points raised above include
The Disadvantages
The Advantages
According to me is quite an easy way out with only one disadvantage. Let me know your thoughts and opinions. I am determined to provide the best solution to our users. |
Not exactly, but don't suffer. I was also lost on the subject, till AJ's comments. Short version: If the UI doesn't allow you to choose a language, that metadata won't be displayed. Why it happens? Take a look to this screenshot form the lang configuration in a testing journal: It show us that you will be able to submit in all langs except Portuguese BUT (this is the relevant part) you won't be able to see the metadata of your articles in PT and IT because the interface (lang selector) don't let you switch to any of those langs than the ones with UI check enabled. At this point, reading this matrix, some questions would rise to you here, like:
Sorry in advance if I have overexplained myself. :-) Back to the thread
The new solution is much better than former one and looks good to me... but apart from the problems you pointed, I will also highlight that:
What do you think about the idea of "Click to switch metadata lang"?
I think I understand you but I'd rather ask than regret. We're not planning to transfer the "red balloon" solution to visitors, are we? If so, it would be a mistake as the solution is already provoking complaints in the backend and exporting it to the frontend would be adding more tongue to the fire. I understand that it would be a much more discreet solution but it would explain why a certain field cannot be displayed with the language requested by the user with the UI language selector, isn't it? Thanks a lot for your work Devika. |
|
@marcbria, before I read your last post till the end :-) : we now have separate submission and UI languages -- submission language can be anything from the weblate list of languages, while UI languages are only those we have translation for... |
Thanks because it answers my question about "Is there a reason to NOT enable the UI in other langs?" (to reach the metadata). |
|
Hey folks, I'm just getting caught up on this conversation and trying to wrap my head around it. I think any movement in this direction is good. Off the top. I just want to say that! Devika, I appreciate all the work you've put into these. I think there's more than one reason for journals to try to display multilingual metadata. Marc said this:
I think this is only half true. The other objective is to give journal options for displaying multilingual metadata so that they're not tempted to jam all their metadata into one field to get them to display at the same time. When I see errors in this space it is almost always about display. "I want to see both". "I want our title to have both languages". "I want both abstracts to be viewable on one record without having to search for it." But, it's possible that this is a cultural difference between what I've seen with Canadian journals and what I've seen with other cultures where bilingualism is a lot less... uhhh... federally complex. But I also want to raise something that A-J said further down:
This is where I think we start to run into problems with multilingual metadata for real. Downstream. When the metadata leaves OJS for other systems. There's two problems:
And Devika has indicated this. And I think the side-by-side option for displayed stuff works. But I do think we need to figure out what we mean by "completeness" in the multilingual space before we figure out what "completeness" in the UI/UX space is. Basically, I don't really know if users need an at-a-glance multilingual view for, like, affiliations. They need titles, abstracts, and then galley labels. We know that much. And I think for major UI/UX refactors knowing what metadata users need, specifically, in this kind of view is good. I'm not confident it needs to be "all available metadata". And, actually, I almost think we should do something more like a DSpace or repository record where you can view all item metadata external to the article view UI. I think I'll also tag @mtub here. I do think the conversations around what's displayed for multilingual metadata and how users see it is a huge issue. There's such a balance between:
|
jyhein
force-pushed
the
f7272
branch
2 times, most recently
from
5a8eef9
to
2c87b0c
Compare
|
Hi, just let you know, I have been reviewing the metadata switching on article page. But still have not figure out how to proceed exactly with it yet. Main issue I have there is with that metadata switcher. From seeing the interactive mockup - it works exactly as html select element - just with custom look. You click on it, and than you can select other one and once you select other one it closes. So I think best for accessibility would be to code it like that. Example of such component with correct accessibility is for example here - https://headlessui.com/v1/vue/listbox (when using for example such headless component its quite straightforward to have custom look as in mock up) And ideally organise it is so the code of the select component itself is not entangled as much with the metadata changing use case. On the reader side we have limited options (no vue.js yet). I have been looking to alpinej, which currently offers headless components and is good fit - does not require build step and is good for adding some JS interactivity. I managed to make it work with it - avoiding any custom JS and relying on alpine for accessibility. But realised that the problem might be that even all alpine code is MIT - the documentation for components/headless components are paywalled, so I am not sure how much we would want to encourage using it going forward. So need to check with team and explore if I can come up with some other alternative. Basically to avoid re-implementing listbox correctly. Ideas/thoughts welcomed. |
|
@jyhein Here is example how the alpine select can be used, so we don't have to reinvent accessible select - 4bf3847 Here are suggestions to improve things
|
Issue: pkp/pkp-lib#9373