Re: [IndexedDB] Languages for collation

On Fri, Aug 13, 2010 at 5:02 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Aug 13, 2010 at 4:56 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Fri, Aug 13, 2010 at 1:31 AM, Pablo Castro <
> Pablo.Castro@microsoft.com>
> > wrote:
> >>
> >> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy
> >> Orlow
> >> Sent: Thursday, August 12, 2010 2:18 AM
> >>
> >> >> I think we should first break down the use cases and look at how many
> >> >> of them just need _a_ sort order, how many of them a per-database
> sort order
> >> >> is ok, and how many of them would need something finer grained (like
> a
> >> >> per-key ordering).
> >>
> >> That's reasonable. What I was thinking is that any case where you'll use
> >> the order of items in a store/index to display things to the user (e.g.
> a
> >> list of contacts) you'd want the items to be in proper order  for the
> user's
> >> language. That will not only match users' expectations but also match
> other
> >> applications (or even other parts of the UA) that display data based on
> the
> >> current OS language or the users' choice of language.
> >>
> >> That covers a very broad spectrum of scenarios that need
> language-specific
> >> sort order.
> >>
> >> I find it unlikely that a single web app will need more than one
> language
> >> per database (or even per origin/OS account), given that most
> applications
> >> operate in a single language at any one point in time.
> >
> > A lot of people are multi-lingual and I'm sure there will be at least
> some
> > apps that need different data sorted in different ways for each language
> > used.  It's quite likely that such apps could use multiple databases as a
> > work-around though.  (As long as they don't need to execute transactions
> > between them.)
>
> I can give some input as a multi-lingual person here. The only time
> I've used multiple languages at the same time in an application is for
> spell checking. In my browser I sometimes end up with setting the
> language in one textbox to swedish, and another to english. It's often
> annoying how poorly this use case is supported in applications
> actually.
>
> However I've never been in a situation where I've wanted some lists
> sorted in swedish and some in english. Possibly you would want to have
> spelling suggestions for a swedish textbox sorted in swedish order,
> and spelling suggestions for an english textbox sorted in english
> order. Though I think it wouldn't be much problem to have the
> different dictionaries in different databases.
>
> From an API point of view I think it would be pretty easy to support
> setting collation for individual objectStores. All we'd need is
> something like:
>
> interface IDBObjectStore {
>  ...
>  IDBRequest setSortingLanguage(in DOMString languageCode);
>  IDBRequest getSortingLanguage();
>  ...
> };
>
> To call setSortingLanguage you'd need READ_WRITE access. It acts just
> like any other writing request, with the only difference that it can
> take a loooong time to execute. We could even add these functions to
> IDBIndex to allow the same data to be sorted in different ways at the
> same time.
>

Why not put it behind setVersion and just make it an optional parameter when
creating objectStores and indexes?  I agree with Pablo that these things
really shouldn't be changing much--in fact, maybe it's not worth making
them modifiable at all (without rebuilding a new objectStore/index
yourself).


> However I think it's very rare that this will be needed. And there are
> ways to somewhat work around it by using separate databases. So I
> would probably say that lets keep it database-wide for now, and
> reconsider in version 2.
>

On the other hand, is there any reason not to make it per-objectStore/index?
 As far as I can tell, it should actually be fairly light weight form an API
point of view: we can just add it as an optional parameter to
createObjectStore/createIndex.  From an implementation point of view, I
really don't see this being much overhead either.  So maybe we should just
do it?

The alternative is to add a function within setVersion to set the language
which actually seems less elegant.

J