Open salaun-urennes1 opened 1 year ago
I have an objection.
Sorting text in descending order by character code does not always result in an intuitively acceptable order (this is especially true for some languages including Japanese and Chinese).
Furthermore, changing the order of items according to language may cause embarrassment during user support. --- "Select the first item in the dropdown list. ...Yes. If the item is written in English, it is the first item".
Would it make sense to have a configuration parameter to control this behavior, thus responding to the need of european users, while leaving the freedom for others to keep the current behavior?
However, sorting by character code may not necessarily be convenient for many European users either. IMO the "à" seems placed after the "z".
That's true, alphabetical sort is not perfect, but still better than the current situation.
Here is an example on our Sympa main server :
That's just why that English and French share many of the same word roots, so the sort order is often the same. In other words, your language is too specific. Check by changing the language setting to Russian, Finnish, Magyar and so on.
If we want to allow users to choose the order they prefer, I think, we need the way something else.
Using Unicode Collate algorthm may solve the problem better for European and other languages (Still only sorting by character code is possible for Kanji, though).
Thanks for suggesting this alternative.
It seems Unicode::Collate is installed on my server. Does it come with Perl?
Using this module for sorting would however require to write a custom sort subroutine to be used in TT2 templates...
Currently Unicode::Collate is not a core module of Perl, but we may be able to add it to our cpanfile
, i.e. we may add it as one of dependency module of Sympa. Of course we need to write any code to use this module in Sympa, but when at last we do, it may be used as easy as builtin sort().
It's midnight here. See you in the next week!
The following opinion is separate from the pros and cons of this PR and may be continued later in a different location.
Currently, users need to distinguish slightly different titles in order to find the appropriate scenario. Sorting would make it easier to distinguish between similar titles by placing them in close proximity to each other. In other words, the fundamental problem may be that there are too many scenarios for each function.
For example, for the send scenario, it would be much easier to understand if several conditions were selected individually, such as:
All possible combinations of these conditions are made into separate scenarios, which means that we have to prepare many scenarios with similar titles.
Thank you for summarizing the problem. I'm on off next week. We can go on this discussion in May...
I agree with you comment; scenario titles are too heterogeneous. Given the number of scenarios, especially for send
, it is hard for list owners to make a clever configuration choice for their list.
At our University we recently made a significant work to simplify the situation:
send
scenarios to find out a) how many lists use each scenario and b) compare the behavior of each scenario. All these informations were summarized in a spreadsheet that looks like this
send
scenario is really worth maintaining (in our context). Others have been hidden using :ignore
files;send
scenarios using a consistent schema. Here is an example: send.ur1modereetrejetsinon:title.fr Owners/Editors: moderated ; staff: mederated ; other: reject
@salaun-urennes1 , I was in the process of doing exactly the same thing (and had given up because I got fed up with the complexity)! If you don't mind, please share the results of your work.
I convert this PR to Draft once. Let's continue discuttion.
Here are further details about our send scenario reorganization:
DDDMMR
means : Accepted ('D') for Owners+Editor+Member, moderated ('M') for staff+students and rejected ('R') for others.default/scenari/send.xx:ignore
files,/data/sympa/etc/scenari/send.confidential:title.gettext Propriétaires/modérateurs: autorisés ; membres: autorisés ; autres: rejet
/data/sympa/etc/scenari/send.editorkey:title.gettext Modérateurs: autorisés ; autres: modérés
/data/sympa/etc/scenari/send.editorkeyonly:title.gettext Tous: modérés
/data/sympa/etc/scenari/send.editorkeyonlyauth:title.gettext Modérateurs: confirmation ; autres: modérés
/data/sympa/etc/scenari/send.newsletter:title.gettext Modérateurs: autorisés ; autres: modérés
/data/sympa/etc/scenari/send.newsletterkeyonly:title.gettext Modérateurs: modérés ; autres: rejet
/data/sympa/etc/scenari/send.private:title.gettext Propriétaires/modérateurs: autorisés ; membres: autorisés ; autres: rejet
/data/sympa/etc/scenari/send.privateandeditorkey:title.gettext Modérateurs: autorisés ; membres: modérés ; autres: rejet
/data/sympa/etc/scenari/send.privatekey:title.gettext Membres: confirmation ; autres: rejet
/data/sympa/etc/scenari/send.privatekeyandeditorkeyonly:title.gettext Modérateurs: confirmation ; membres: modérés ; autres: rejet
/data/sympa/etc/scenari/send.privateoreditorkey:title.gettext Modérateurs: autorisés ; membres: autorisés ; autres: modérés
/data/sympa/etc/scenari/send.privateorpublickey:title.gettext Membres: autorisés ; autres: confirmation
/data/sympa/etc/scenari/send.public:title.gettext Tous: autorisés
/data/sympa/etc/scenari/send.public_nobcc:title.gettext Tous: autorisés ; copie cachée: rejet
Here is the list of scenarios we ignore :
./default/scenari/send.owner:ignore
./default/scenari/send.private_smime:ignore
./default/scenari/send.newsletterkeyonly:ignore
./default/scenari/send.privateoreditorkey:ignore
./default/scenari/send.privateandnomultipartoreditorkey:ignore
./default/scenari/send.intranetorprivate:ignore
./default/scenari/send.privateandeditorkey:ignore
./default/scenari/send.private:ignore
./default/scenari/send.editorkey:ignore
./default/scenari/send.editorkeyonlyauth:ignore
./default/scenari/send.publicnomultipart:ignore
./default/scenari/send.default:ignore
./default/scenari/send.privateorpublickey:ignore
./default/scenari/send.public:ignore
./default/scenari/send.ownerauth:ignore
./default/scenari/send.editordkim:ignore
./default/scenari/send.publicnoattachment:ignore
./default/scenari/send.publickey:ignore
./default/scenari/send.newsletter:ignore
./default/scenari/send.public_nobcc:ignore
./default/scenari/send.privatekey:ignore
./default/scenari/send.privatekeyandeditorkeyonly:ignore
./default/scenari/send.closed:ignore
./default/scenari/send.intranet:ignore
./default/scenari/send.editorkeyonly:ignore
Currently scenario in edit_list_request pages are sorted on scenario filenames. As reported in https://lists.sympa.community/msg/fr/2023-04/1TZ5Q-_qRxSqJkG0zscNjQ, it would make sense to sort them on scenario titles.
This PR does the sort in TT2 file