ubuntu-appstore-developers team mailing list archive

[James Tait <james.tait@xxxxxxxxxxxxx>]

-----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
> <james.tait@xxxxxxxxxxxxx> 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-----