Ticket #547 (new enhancement)

Opened 14 years ago

Last modified 10 years ago

Search returns the same proxies in all the their available translations.

Reported by: madarche Owned by: trac
Priority: P3 Milestone: CPS 3.5.7
Component: CPSDefault Version: unspecified
Severity: normal Keywords:
Cc:

Description (last modified by fguillaume) (diff)

Search returns the same proxies in all the their available translations.

Step to reproduce


Go in the workspaces folder.

Go to the advanced search form  http://localhost:8080/cps/workspaces/advanced_search_form

Search for all the content types from "Here".

You will get the "workspaces" object entry *twice".

=> Search returns the same proxies in all the their available translations.

The same problem is encountered when one wants to use CPS3/CPSDefault/skins/cps_default/search.py to programmaticaly retrieve objects from a location.

One solution would be to add to the "search.py" script a parameter to not display the different translations of the same proxy or something.

Change History

comment:1 Changed 14 years ago by bdelbosc

  • Priority changed from P2 to P3

I don't see this behaviour as a bug,

you are searching for all available document (in all languages by default) that is exactly what you get.

Displaying only one language when requesting for all documents is a bug.

I think the problem is that we simply miss a language criteria in the search form, if the search form contains 'all languages' having 'Workspaces' and 'Espaces de travail' in the result list is fine and understandable.

(changing priority to P3 at least)

comment:2 Changed 14 years ago by madarche

Functionnaly speaking this is a bug. No one will benefit from the current behavior. CPS is for the users.

The user interface that I would like to have is: only return one proxy path, no matter which languages are available for the document.

If later on we want to add a language criteria to the search, fine with me. But this criteria should not be set by default because websites are generally only partly translated and a full search, no matter the languages, will be more usefull.

comment:3 Changed 14 years ago by bdelbosc

I disagree, from a user point of view seing brazilian and english version of the same document is important.

because:

  • for the user there are 2 documents one brazilian and one in english
  • the submited query matches both of them
  • normal user will not notice that they are sharing the same url

It is not understandable for a user that a returned document don't match his query or a document is missing from the result, this remove a way to access information.

For the 'language criteria' in the search form, of course the default value will be 'all languages'.

comment:4 Changed 14 years ago by madarche

Hummm...

Could other people give their views on the subject?

comment:5 Changed 14 years ago by janguenot

+1 for ben's comment. We need a language criteria.

comment:6 Changed 14 years ago by madarche

Julien, and how do you do to programmaticaly get all the proxies *without duplicates* located in a folder?

Isn't it the job of the search.py script?

I do think so. Thus the search.py script needs to be updated so that it's possible to have it return no proxy duplicates.

comment:7 Changed 14 years ago by atchertchian

Let's say +1 for the language criteria, but I agree with Marc-Aurèle that this is not the best way to present it to users. Is there any way to gather the different versions in different languages? I don't know if it's easy or not, but I think it would be quite good to have results approaching:

  • test (2 langues)
    • 01/31/2005 07:33 PM: v1- English work , 1 K /cps/workspaces/test/switchLanguage/en
    • 03/16/2005 12:37 PM: v2- French work , 1 K /cps/workspaces/test/switchLanguage/fr
  • test2 03/16/2005 12:38 PM: v1- French work , 1 K /cps/workspaces/test/test2

comment:8 Changed 14 years ago by madarche

I like Anahide's proposition.

But there is another problem which is not user interface related: How to programmaticaly get all the proxies located in a folder *without duplicates* through the use of the CPSDefault/skins/cps_default/search.py script?

Should I have opened a separate bug? I don't think so because the search_form directly call search.py

comment:9 Changed 14 years ago by bdelbosc

Anahide what is 'test' in your example ?

  • the title ? each languages have a different one
  • the url -> users are not seeking urls but documents

For the second point if you want to retrieve all proxies located in a folder (using a search :/ ) we need to add a boolean index like default_version. Then we can also have a 'VO' search criteria in the search form.

comment:10 Changed 14 years ago by atchertchian

Ok, let's say my current language is English

  • English test 01/31/2005 07:33 PM: v1- English work , 1 K /cps/workspaces/test/switchLanguage/en

Available in other languages:

  • French: Test français 03/16/2005 12:37 PM: v2- French work , 1 K /cps/workspaces/test/switchLanguage/fr
  • Spanish: Testo :) 03/16/2005 12:37 PM: v2- Spanish work , 1 K /cps/workspaces/test/switchLanguage/es
  • Only available in other languages:
    • French: Test français bis 03/16/2005 12:37 PM: v2- French work , 1 K /cps/workspaces/test2/switchLanguage/fr
    • Spanish: Testo biso :) Réassigner le bug au propriétaire du composant

sélectionné

03/16/2005 12:37 PM: v2- Spanish work , 1 K /cps/workspaces/test2/switchLanguage/es

  • My interesting document 03/16/2005 12:38 PM: v1- English work , 1 K /cps/workspaces/my_interesting_doc/

I would also like to point ou that clients are often complaining when they have useless language indications when they only use one language, so I think we have to take care of the case where only one language is used.

comment:11 Changed 14 years ago by bdelbosc

concerning the current bug: 'Search returns the same proxies in all the their available translations.'

I just add a new filter set cps_filter_sets:default_languages that return all proxies in their default languages (plus all non proxy objects) so it can be used with the searchable filter set

I have also updated search.py to handle a new parameter 'default_languages' this is describe in search.py: ... # the 2 previous searches will return all the documents that are pointed by # proxies that are located below the folder1, # this means that if you have a proxy that contains 3 translations you # will have 3 brains for this proxy. # If you want only a list of proxies in their default languages without # the available translation: brains = portal.search(query={'path': '/cps/workspaces/folder1'},

default_languages=1)

note that you need to delete cps_filter_sets index via the zmi before running the cpsupdater (cpsinstaller is not clever enought to see that a topic index definition have changed).

Concerning the Anahide's grouped search result, it sounds nice but:

  • this is not very relevant for a search result, in most of the case result are

sorted by something which is not easy to mix with grouping

  • it is quiet hard/inefficient to implement, this require to preprocess all the

brains, loosing all catalog benfits :(

nevertheless I understand the need for a better folder content representation -> thanks to fill another a bug

concerning the last point 'site which use only one language' this is true ! -> thanks to fill another bug

comment:12 Changed 14 years ago by fguillaume

  • Milestone changed from unspecified to CPS 3.5.0
  • Severity changed from normal to enhancement
  • Description modified (diff)

comment:13 Changed 10 years ago by gracinet

  • Milestone changed from CPS 3.5.0 to CPS 3.5.2

the search.py skins script should now be considered the controller for the simple/advanced search views.

Programmatic stuff should not rely on it, but use the catalog API instead.

Grouping seems without losing the catalog benefits in case of sorting/batching looks difficult indeed.

Note: See TracTickets for help on using tickets.