Feature #5234

Add language facets to support multi-culture search/browse usability

Added by Dan Gillean almost 9 years ago. Updated over 7 years ago.

Status:VerifiedStart date:06/12/2013
Priority:MediumDue date:
Assignee:Dan Gillean% Done:

0%

Category:Search / BrowseEstimated time:12.00 hours
Target version:Release 2.1.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

As described in issue #5229, currently if a user is unaware that there are descriptions in more than one language/culture, they may be confused why certain repositories list no results when selected, though the facet itself suggests there should be hundreds of records present.

In 2.x, we have decided not to maintain culture fallback in the same was as 1.x - this will have the advantage of allowing a user to search across all results, but it requires some usability enhancements for this to be clear to the end user.

  1. All search/browse pages should offer "Language" as a facet, with a count of available records next to them.
  2. When a user visits a repository page (or other page) where there are more records available in another language, the current language should appear clearly at the top as a search filter with an X that can be removed by the user to see all results

Further testing will need to be done to consider other usability enhancements for supporting multiple languages in AtoM, but these first two steps will go a long way in addressing the issue, whereupon remaining gaps in usability can be identified and addressed. The goal should be to make the separation as clear to the end user as possible, so they are not confused about the results returned, and have the option of viewing further records without having to switch the culture of the entire application interface.


Related issues

Related to Access to Memory (AtoM) - Bug #5229: Repository Facet Results for Browse Archival descriptions... Invalid 06/11/2013

History

#1 Updated by Dan Gillean almost 9 years ago

  • Description updated (diff)

#2 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from New to In progress

#3 Updated by Jesús García Crespo almost 9 years ago

Planning to store an array of strings with the available cultures within the i18n object, since I can't find a way to build a facet matching all the language objects keys (i18n.en, i18n.fr, etc...). Once I have that array indexed, I should be able to do something like the following:

{
  "query": {
    "match_all": {}
  },
  "facets": {
    "languages": {
      "terms": {
        "field": "i18n.languages" 
      }
    }
  }
}

Response:

{
  [...],
  facets: {
    languages: {
      [...]
      terms: [
        { term: en, count: 192 },
        { term: fr, count: 1025 }
      ]
    }
  }
}

#4 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from In progress to QA/Review

This is working now, but I feel like it's going to need some tuning. With large data sets, it's hard to tell if the facets are counting properly, we'll have to test with small sets. I've been doing some testing locally and it seems to work, but I'm still not very confident due to its complexity.

#5 Updated by Dan Gillean almost 9 years ago

  • Status changed from QA/Review to Feedback

This isn't yet solving the use case presented in #5229 and the top of this issue ticket - users do not have the option to view all descriptions when viewing a repository record - see for example: http://archivescanada.accesstomemory.org/archives-nationales-du-quebec-montreal - then switch culture to French.

Unless the user thought to switch into the french mode for the entire site, they would not know that this institution holds over 1000 archival descriptions.

Similarly, the filter included on the archival description browse page should ideally include an "all" option - users who wish to see all records regardless of language should have the option of doing so. otherwise a user basically has to do the same searching/browsing twice, in english and in french. searching may return results in both languages but if browsing is not, this still presents a problem.

#6 Updated by Jesús García Crespo almost 9 years ago

  • Estimated time set to 12.00

#7 Updated by Jesús García Crespo over 8 years ago

  • Status changed from Feedback to New
  • Assignee changed from Jesús García Crespo to José Raddaoui Marín

#8 Updated by José Raddaoui Marín over 8 years ago

  • Status changed from New to In progress

#9 Updated by José Raddaoui Marín over 8 years ago

Hi Dan and Sevein,

After the fix for #5723, the issue Dan mentioned about the repository view page is solved, now you can see all the holdings in whatever culture you are.

I've started to add the 'all' option in the languages facet, but I don't know if this is a good idea, this facet is intended to work as is working, with a few exceptions with the other facets to do so. Also, there is no need to do the same browse/search twice, if there are results in other language for the same search/browse they'll appear in that facet, and you just need to click the language to see them.

So, what is left to do here?

Thanks!

#10 Updated by Jesús García Crespo over 8 years ago

  • Target version changed from Release 2.0.0 to Release 2.0.1

Let's revisit this later after the release!

#11 Updated by Jesús García Crespo over 8 years ago

  • Status changed from In progress to New

#12 Updated by Tim Hutchinson over 8 years ago

Further to the user group thread, in case this isn't part of the known limitations ...

Testing in the AC beta (and reproduced locally), I noticed that if a searchable term occurs ONLY in French, a search for it will not return any results, even from the French interface.

E.g. try searching for "vestiges", which occurs here:

http://archivescanada.accesstomemory.org/fonds-yolande-allard

#13 Updated by Jesús García Crespo over 8 years ago

  • Target version changed from Release 2.0.1 to Release 2.1.0

#14 Updated by Tim Hutchinson over 8 years ago

Hi,
Continuing to refine requirements for #5968...
In adding facet blocks to several pages, I was assuming we should add the language facet as well, for consistency with the existing facet blocks. However, I wanted to check that, especially since the current issue is still open. Is it worth adding the language facet to additional browse pages using the existing coding, or should we leave it out for now?

#15 Updated by Dan Gillean over 8 years ago

Hi Tim, Jesus is really busy with client work at the moment, but as our AtoM Systems Architect, he will be the best person to discuss this with. I will try to get him to take a look at this issue in the next bit. As it stand right now however, since this feature is unsponsored and 2.1 is looking to be really full of client-sponsored work, there is a good chance this may not get addressed in the next major release. As such, my guess would be that it makes sense to proceed by adding the language facet to any page you are working on - i think the plan will be to merely improve the existing functionality without radically altering the existing facet structure. As I said, I will try to get input from Jesus for you, for a fuller response.

#16 Updated by Tim Hutchinson over 8 years ago

Great, thanks Dan.

#17 Updated by Jesús García Crespo over 7 years ago

  • Target version changed from Release 2.1.0 to Release 2.2.0

#18 Updated by José Raddaoui Marín over 7 years ago

  • Status changed from New to QA/Review
  • Assignee changed from José Raddaoui Marín to Dan Gillean

Hi Dan, was this fixed as part of #7120?

#19 Updated by Dan Gillean over 7 years ago

  • Status changed from QA/Review to Verified
  • Target version changed from Release 2.2.0 to Release 2.1.0

Good catch Radda! Marking verified but assigning back to 2.1 so we don't list it accidentally in the 2.2 release notes when it's time. I did test the use case that Tim describes in comment 12 above, and it looks like the changes we made for #7120 resolves this in both cultures, which is great!

Also available in: Atom PDF