-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/06/13 20:11, Martin Albisetti wrote: > On Mon, Jun 24, 2013 at 6:56 AM, James Tait > <[email protected]> wrote: >> >> The problem with the latter approach, as I currently understand >> it, is that it would be indexed on the language key, so I'm not >> sure if we'd be able to search on the actual localised >> description text. On the other hand, it does make the >> localisation mostly transparent - we just select the description >> field regardless of the language we want, and probably return the >> appropriate version based on the request headers or an optional >> query parameter, rather than having to mangle the request to >> append the localisation suffix to field names. > > > I think this is key, being able to search on the localisation is > probably required to deliver a good experience. Let us know :)
The localisation is on the fieldType, not the field itself. So we need to declare a fieldType for each of the languages Solr supports that we want to make available, then declare a field per language for each of the localisable fields. For the user-facing portion of this, I propose something like the following: - If the query specifies a localisation (e.g. q=description_en:foo), we should use it. - Similarly, if a specific localised result field is requested (e.g. fl=description_en), we should use it. - In the general case, clients should use the non-localised field name in queries (q=description) and result fields (fl=description) and provide an Accept-Language header, which we will use to choose the localised variant. This keeps the query API flexible, but avoids unnecessary complexity in the general case. On 24/06/13 14:21, Colin Watson wrote:> On Mon, Jun 24, 2013 at 02:00:28PM +0100, James Tait wrote: >> I'm not sure how we deal with a request for a field that doesn't >> have the requested localisation (maybe we just return the >> default, whatever that is), but otherwise it should be >> transparent, I think. > > It would be usual to just return the English text in that case. Which implies that the English version of the localisable fields would be required, and we return <field>_en in cases where <field>_<lang> is not available. If this sounds reasonable I'll write it up in the wiki [0] and make the necessary schema changes. Cheers, JT [0] https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex - -- James Tait, BSc. | https://launchpad.net/~jamestait/ Software Engineer, Canonical Online Services, Web and Ops Team Ubuntu - Linux for human beings | www.ubuntu.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlHKtPIACgkQyDo4xMNTLiZzrQCgprw5deR6RiYgl8eVDzyVFJ3e DOEAoPI94eDUWwZSWG7BvrxDj3HnLIGu =Ircr -----END PGP SIGNATURE----- -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
