Feature #8964

Alphabetic sort fails when results appear in multiple cultures

Added by Dan Gillean over 6 years ago. Updated over 5 years ago.

Status:FeedbackStart date:09/16/2015
Priority:MediumDue date:
Assignee:-% Done:


Target version:-
Sponsored:No Tested version:2.2, 2.3


To reproduce:
  • Import a number of descriptions with linked place or subject access points, in the same culture as the default UI culture
  • Flip the user interface to french
  • Create new place/subject terms - A, B, C, D, etc. Save.
  • Flip the user interface back to english
  • Browse the results, sorted alphabetically
Resulting error
  • French terms appear after English terms
  • French terms are not even organized alphabetically amongst themselves
Expected result
  • All terms organized alphabetically regardless of culture

This seems to be caused by culture fallback - when using Alphabetic sort, the results in the culture that match the default user interface culture are presented first. After those, results in other cultures are presented - but do not seem to conform to ASCII-sorted alphabetic order. The cause may be that in the default UI culture, there is no title, so when culture fallback adds the resources, it is adding a bunch of resources with NULL titles; perhaps the results, all being equal, are in fact ordered by most recent or something. Not sure - but culture fallback is definitely involved.


#1 Updated by David Juhasz over 6 years ago

I would guess that the alias used for the fallback column (https://github.com/artefactual/atom/blob/ce1e01887e4acaa1cd94ffe1f543cf9ec842e028/lib/QubitCultureFallback.class.php#L41) is not working properly and it's being confused with the real term_i18n.name column when sorting. I would try using a unique alias (e.g. 'nameFallback') for the calculated fallback value.

#2 Updated by Mike Gale over 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from Mike Gale to José Raddaoui Marín

I wouldn't mind Radda's opinion on how hard it'd be to fix this

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

  • Assignee changed from José Raddaoui Marín to Mike Gale

This is something that happens in all alphabetic sortings that use ES. We only sort over the current culture title, name, etc., and many are empty in different cultures:


We could add sorting fields in the ES index for all types, populate it doing the sourceCulture fallback, and use it as the sorting field.

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

Well, that may not be the best solution, as we will always sort in the source culture title of each record, and if they are populated in other cultures, it will show the current culture title but it will be sorted using the source culture title ...

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

Ok, we could add a sorting field in all available cultures 'i18n.en.sortTitle', 'i18n.fr.sortTitle', etc. That field will be populated with the same culture title if exists or, if it doesn't, the sourceCulture title. This is the same we do in the interface for culture fallback, so the titles being displayed will be the same as the titles used for sorting.

This will require some changes on how the mapping is created and how the i18n fields are populated in ES, we will need and option in our mapping like we have for the raw and autocomplete fields.

#6 Updated by David Juhasz over 6 years ago

Cool! Radda, do you have a time estimate to add the sortTitle fields?

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

I think 12-16 hours. It will be needed in all index types and maybe more than one field for different sortings.

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

  • Tracker changed from Bug to Feature
  • Project changed from Access to Memory (AtoM) to AtoM Wishlist
  • Category deleted (Search / Browse)

#9 Updated by David Juhasz over 5 years ago

  • Assignee deleted (Mike Gale)

Also available in: Atom PDF