https://bugzilla.wikimedia.org/show_bug.cgi?id=8732

--- Comment #12 from Philippe Verdy <verd...@wanadoo.fr> 2011-01-31 22:19:51 
UTC ---
OK jquery makes this cleaner to manage, but this does not solve the general
problem of correct locale-specific collation orders, because jQuery still does
not handle any tailored collation comparator.

The main problem is still there: if it's computationally expensive to create
such collator in IE, the alternative will be to have the collation keys
computed on the server side, using AJAX, even if the set of strings (from which
the collation keys will be computed) is retrieved from the DOM using AJAX.

The server-side script could either return the collation keys as an array from
an array of source strings (that could then be stored in an hidden data field
of sortable cells, so that these keys will be AJAX-requested only once), or a
compact index of integers saying how to reposition the elements in the
AJAX-submitted string.

Anyway, I still think that AJAX would just make the page much slower to respond
to sort requests. On the opposite, the tables could be generated with hidden
data already containing all the collation keys where appropriate. But it could
still be a good fallback option, if support on the client-side is not possible
in some browsers (jQuery could help detecting when Ajax will be required, and
when the collator can be fully written in Javascript to run on the client
side).

For now, the current jQuery solution assumes that the sort key gets computed
from the visible strings in each cell, but it should allow taking the sort keys
from an hidden data field in the same cell (using the "custom sort" solution
described in the article, this is not really possible as the source is only the
cell's inner text content).

I think that the jQuery team should start a project to create a portable
client-side collator (with such fallback to a server side Ajax+JSON script, the
server-side collator being able to use any kind of server language: in PHP, or
Perl, or C with ICU, or Ruby... and not necessarily the same server as the one
serving the web pages using jQuery : Google for example has developped a
reusable Google API to do that, just like it has developed an open webfont
server API usable in Google Documents or in any other site).

To be allowed to generate the collation sort keys directly within the HTML of
the table, we should still have a MediaWiki builtin function that can be called
when appropriate, to generate a binary-sortable string that can be used
directly from the standard "<=" operator of Javascript. So jQuery would just
have to use this comparator (and this would not be computationally intensive in
any browser, and could work on smartphones).

The builtin MediaWiki parser function to compute the collation keys would just
need two parameters: the source text, and a locale id. There already exists the
code needed in ICU4C, already integrable in PHP (look for ICU4PHP), and that
can be used in a MediaWiki extension to create the necessary parser function
with minimal efforts.

I even bet that native integration of ICU will become standard in the PHP core
distribution, because it will allow better interoperability between
heterogeneous database engines for sorting data, and will remove the
interoperability problems caused by the implicit need of support within the
native C libraries used on each system for which PHP was compiled.

Note that HTML5 has standardized the "dataset" feature, i.e. a normative naming
scheme that allows hiding one or several data elements as additional attributes
of any kind of elements.

The "dataset" works for classic HTML, as long as you don't need a strict DTD
where all attribute names must be declared; but given that the DTD declaration
is completely deprecated in HTML5 (and the support of the dataset feature is
mandatory for HTML5 compliance), this is not an issue.

For XML/XHTML, you may use an external DTD or XML Schema to declare these
"data-*" attribute names, but this would not work with MediaWiki that won't
allow you to add such declaration ; but MediaWiki does not use the HTML Strict
model, and we could still be compatible with XHTML by adding a standard default
"data-collation-key" attribute name declaration in the generated document, if
pages are not served in HTML5 ; if pages are served in HTML5, nothing is
required, we don't need any declaration.

(I don't know if MediaWiki can selectively generate HTML5, or XHTML with XML
Schema, or XHTML with DTD, or HTML4, depending on the query capabilities of the
source browser ; my opinion is that it should be able to do that, as easily as
it can create HTML specially tuned for limited smartphones, or pages rendered
in WAP or iMode format for older phones, or pages for accessibility devices
like Aural/Braille renderers... or pages in other future standard formats, or
less open formats with other user-interactivity types such as PDF, Flash,
SilverLight... which may come up and would require specific development for
each of them, even if this is not the current work target for MediaWiki whose
primary focus is still HTML4 and its optional newer extensions).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to