Handling of author last names starting with a diacritic in author list

In the old forum, there was a lengthy blog post about a problem regarding characters with diacritics at the beginning of author last names. This results in a problem with the headlines that are displayed in OJS. To summarize the main points:

  • The alphabetical sorting of items in the author list is done by the database and the server.
  • After sorting, the list is displayed by OJS using smarty code. I would like to address a problem with this code.

In authorIndex.tpl, the condition for a new headline is:
if $lastFirstLetter|lower != $firstLetter|lower

This causes a problem in situations like the following: A journal has authors with their last names starting wit A, Ä, K, Ǩ, Z and Ż. For sorting, they would like those letters to be treated as if they had no diacritics. They configure their server to return the correct sorting order. Now, the last names are processed by OJS code to determine when to place a new heading. Because "A" == "Ä" returns false, every time a letter without diacritic is followed by one with diacritic and vice versa, a new letter headline is displayed.

See this example:

We have come across this issue quite frequently. To solve it, I’d like to propose the following:

  1. Create a localisation string that contains the sorting order. I have sketched the following format, where all letters to be displayed without new letter headline should be written after the basic letter and before the following comma: "A Ä,B,C,D,E,F,G,H,I,J,K Ǩ,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z Ż"
  2. The string would be read through the smarty localization functions and passed to the code in authorIndex.tpl, but would not be displayed.
  3. The if clause in authorIndex.tpl would need to be replaced by some code parsing and applying the sorter settings string.
  4. People would still have to correctly configure their server to sort the author data according to the needs (database and php).

There is a pull request with the php code to replace the if clause currently used. However, I am not sure what would be the best way to handle the settings string for the sort order. It shouldn’t be hardcoded, that is obvious, but introducing it as a localisation string would be a significant change. Any input would be very appreciated!

The result, using the same data as in the screenshot above and the code from the pull request:

1 Like

Hi @ojsbsb,

Thanks for contributing! I’ll carry on the discussion on that pull request.

Regards,
Alec Smecher
Public Knowledge Project Team