You are describing the idea pretty accurately. Apparently Endeca has something that sort of supports this, which we used for the problem.
On Thu, Aug 31, 2017 at 1:59 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > ok, so lemme attempt to restate your objective to ensure no > miscommunication: > > 1) you have fields like "color" > 2) you want to index english words into the color field for docs > 3) you want to search/filter against these fields using english words as > input > 4) you want to facet on the fields like "color" > 5) you want the list of terms:counts displayed to the end user when > faceting on these fields to be in a variety of different langauges, based > on a "user_lang" option specified at query time and a set of known > translations > 6) if no english->user_lang translation is available for a particular > term, you want to display the eglish workd when displaying the facet > counts > > does that sound right? > > based on your objective, attempting to embed/encode the various > translations into the terms when indexing (as payloads, or an > alternative field or prefixed terms, etc...) seems like a vastly > overcomplicated way to deal with this problem. > > If i were in your shoes, i would keep the translation aspect of the > displya completely distinct from Solr, and after solr has returned the > response then loop over the facet.field temrs and do a lookup in some > other (cached) key/value translation mapping in your middle layer -- > replacing the english word with the translation if it exists. > > This has the added benefit of allowing you to tweak the translations w/o > reindexing any docs. > > Practically speaking: the idea of encoding these translations as payloads > wouldn't make sense -- because payloads exist per *occurance* of the term > -- ie: it wouldn't make sense to put "es=rojo;fr=rouge" in the payload of > a term "red" when indexing a document, because you want those translations > for all instances of red -- not just that instance of red in that > singlular document. > > > > : Date: Mon, 28 Aug 2017 13:29:00 -0500 > : From: Webster Homer <webster.ho...@sial.com> > : Reply-To: solr-user@lucene.apache.org > : To: solr-user@lucene.apache.org > : Subject: Re: Facet on a Payload field type? > : > : The issue is, that we lack translations for much of our attribute data. > We > : do have English versions. The idea is to use the English values for the > : faceted values and for the filters, but be able to retrieve different > : language versions of the term to the caller. > : If we have a facet on color if the value is red, be able to retrieve rojo > : for Spanish etc... > : > : Also users can switch regions between searches. If a user starts out in > : French, executes a search, selects a facet then switches to German they > : should get the German for the facet (if it exists) even when they > : originally used French. If all of the searching was in English where we > : have the data, we could then show French (or German etc) for the facet > : value. > : > : The real field value that we use for filtering would be in English but > the > : values returned to the user would be in the language of their locale or > : English if we don't have a translation for it. The idea being that the > : translations would be stored in the payloads > : > : On Wed, Aug 23, 2017 at 7:47 PM, Chris Hostetter < > hossman_luc...@fucit.org> > : wrote: > : > : > > : > : The payload idea was from my boss, it's similar to how they did this > in > : > : Endeca. > : > ... > : > : My alternate idea is to have sets of facet fields for different > : > languages, > : > : then let our service layer determine the correct one for the user's > : > : language, but I'm curious as to how others have solved this. > : > > : > Let's back up for a minute -- can you please explain your ultimate > goal, > : > from a "solr client application" perspective? (assuming we have no > : > knowledge of how/how you might have used Endeca in the past) > : > > : > What is it you want your application to be able to do when indexing > docs > : > to solr and making queries to solr? give us some real world examples > : > > : > > : > > : > (If i had to guess: i gather maybe you're just dealing with a > "keywords" > : > type field that you want to facet on -- and maybe you could use a diff > : > field for each langauge, or encode the langauges as a prefix on each > term > : > and use facet.prefix to restrict the facet contraints returned) > : > > : > > : > > : > https://people.apache.org/~hossman/#xyproblem > : > XY Problem > : > > : > Your question appears to be an "XY Problem" ... that is: you are > dealing > : > with "X", you are assuming "Y" will help you, and you are asking about > "Y" > : > without giving more details about the "X" so that we can understand the > : > full issue. Perhaps the best solution doesn't involve "Y" at all? > : > See Also: http://www.perlmonks.org/index.pl?node_id=542341 > : > > : > > : > > : > : > : > : On Wed, Aug 23, 2017 at 2:10 PM, Markus Jelsma < > : > markus.jel...@openindex.io> > : > : wrote: > : > : > : > : > Technically they could, facetting is possible on TextField, but it > : > would > : > : > be useless for facetting. Payloads are only used for scoring via a > : > custom > : > : > Similarity. Payloads also can only contain one byte of information > (or > : > was > : > : > it 64 bits?) > : > : > > : > : > Payloads are not something you want to use when dealing with > : > translations. > : > : > We handle facet constraint (and facet field) translations just by > : > mapping > : > : > internal value to a translated value when displaying facet, and > vice > : > versa > : > : > when filtering. > : > : > > : > : > -----Original message----- > : > : > > From:Webster Homer <webster.ho...@sial.com> > : > : > > Sent: Wednesday 23rd August 2017 20:22 > : > : > > To: solr-user@lucene.apache.org > : > : > > Subject: Facet on a Payload field type? > : > : > > > : > : > > Is it possible to facet on a payload field type? > : > : > > > : > : > > We are moving from Endeca to Solr. We have a number of Endeca > facets > : > : > where > : > : > > we have hacked in multilangauge support. The multiple languages > are > : > : > really > : > : > > just for displaying the value of a term internally the value > used to > : > : > search > : > : > > is in English. The problem is that we don't have translations for > : > most of > : > : > > our facet data and this was a way to support multiple languages > with > : > the > : > : > > data we have. > : > : > > > : > : > > Looking at the Solrj FacetField class I cannot tell if the value > can > : > : > > contain a payload or not > : > : > > > : > : > > -- > : > : > > > : > : > > > : > : > > This message and any attachment are confidential and may be > : > privileged or > : > : > > otherwise protected from disclosure. If you are not the intended > : > : > recipient, > : > : > > you must not copy this message or attachment or disclose the > : > contents to > : > : > > any other person. If you have received this transmission in > error, > : > please > : > : > > notify the sender immediately and delete the message and any > : > attachment > : > : > > from your system. Merck KGaA, Darmstadt, Germany and any of its > : > : > > subsidiaries do not accept liability for any omissions or errors > in > : > this > : > : > > message which may arise as a result of E-Mail-transmission or for > : > damages > : > : > > resulting from any unauthorized changes of the content of this > : > message > : > : > and > : > : > > any attachment thereto. Merck KGaA, Darmstadt, Germany and any > of its > : > : > > subsidiaries do not guarantee that this message is free of > viruses > : > and > : > : > does > : > : > > not accept liability for any damages caused by any virus > transmitted > : > : > > therewith. > : > : > > > : > : > > Click http://www.emdgroup.com/disclaimer to access the German, > : > French, > : > : > > Spanish and Portuguese versions of this disclaimer. > : > : > > > : > : > > : > : > : > : -- > : > : > : > : > : > : This message and any attachment are confidential and may be > privileged or > : > : otherwise protected from disclosure. If you are not the intended > : > recipient, > : > : you must not copy this message or attachment or disclose the > contents to > : > : any other person. If you have received this transmission in error, > please > : > : notify the sender immediately and delete the message and any > attachment > : > : from your system. Merck KGaA, Darmstadt, Germany and any of its > : > : subsidiaries do not accept liability for any omissions or errors in > this > : > : message which may arise as a result of E-Mail-transmission or for > damages > : > : resulting from any unauthorized changes of the content of this > message > : > and > : > : any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its > : > : subsidiaries do not guarantee that this message is free of viruses > and > : > does > : > : not accept liability for any damages caused by any virus transmitted > : > : therewith. > : > : > : > : Click http://www.emdgroup.com/disclaimer to access the German, > French, > : > : Spanish and Portuguese versions of this disclaimer. > : > : > : > > : > -Hoss > : > http://www.lucidworks.com/ > : > > : > : -- > : > : > : This message and any attachment are confidential and may be privileged or > : otherwise protected from disclosure. If you are not the intended > recipient, > : you must not copy this message or attachment or disclose the contents to > : any other person. If you have received this transmission in error, please > : notify the sender immediately and delete the message and any attachment > : from your system. Merck KGaA, Darmstadt, Germany and any of its > : subsidiaries do not accept liability for any omissions or errors in this > : message which may arise as a result of E-Mail-transmission or for damages > : resulting from any unauthorized changes of the content of this message > and > : any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its > : subsidiaries do not guarantee that this message is free of viruses and > does > : not accept liability for any damages caused by any virus transmitted > : therewith. > : > : Click http://www.emdgroup.com/disclaimer to access the German, French, > : Spanish and Portuguese versions of this disclaimer. > : > > -Hoss > http://www.lucidworks.com/ > -- This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.emdgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.
