Brion Vibber schrieb:
> El 5/11/09 5:04 PM, Ariel T. Glenn escribió:
>> Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber
>>> Since download time is a concern, we'd generally be looking for smaller
>>> font sets, such as one that covers specifically the language of an
>>> individual
I don't know about Safari, but Firefox 3.5 first renders the text and then
downloads the fonts and rerenders, if I read this correctly:
"When rendering a page using downloaded fonts, Firefox first renders using
available fonts, then updates the display as downloadable fonts are
retrieved. This all
Petr Kadlec wrote:
> The problem is much more difficult than that (see the linked
> bug). Commas, case sensitivity and whitespace are a trivial
> problem in comparison with non-ASCII letters.
It is exactly this attitude of "oh, it's so difficult" that has
blocked bug 164 from being fixed. I d
2009/5/12 Lars Aronsson :
> Petr Kadlec wrote:
> It is exactly this attitude of "oh, it's so difficult" that has
> blocked bug 164 from being fixed.
Well, not really. Bug 164 would be fixed almost completely for
Czech-language wikis by using database features designed for exactly
this problem. [1]
On Mon, May 11, 2009 at 3:27 PM, Brian wrote:
> In my opinion fragmentation of conversations onto evermore mailing lists
> discourages contribution.
I have to agree that I don't think the dump discussion traffic seemed
large enough to warrant a whole new mailing list.
___
On Mon, May 11, 2009 at 2:50 PM, Daniel Schwen wrote:
> The simple (albeit ugly) solution would to add a parser version field to the
> revision table, drag the old parser along as 'legacy', make the new parser
> the default (and only) option for all new edits, and spit out a warning when
> you ar
On Tue, May 12, 2009 at 4:16 AM, Bence Damokos wrote:
> I don't know about Safari, but Firefox 3.5 first renders the text and then
> downloads the fonts and rerenders, if I read this correctly:
Yes, that's what I understand as well. It was discussed on www-style
just a little while ago:
http://
On Mon, May 11, 2009 at 3:29 PM, Lars Aronsson wrote:
> There is a way to avoid all such problems, namely by a more
> aggressive use of DEFAULTSORT that removes from sorting all upper
> case letters (except the initial one), all whitespace and all
> commas. It would mean almost every article need
Aryeh Gregor wrote:
> On Mon, May 11, 2009 at 3:27 PM, Brian wrote:
>> In my opinion fragmentation of conversations onto evermore mailing lists
>> discourages contribution.
>
> I have to agree that I don't think the dump discussion traffic seemed
> large enough to warrant a whole new mailing list
El 5/12/09 4:18 PM, Petr Kadlec escribió:
> 2009/5/12 Lars Aronsson:
>> Petr Kadlec wrote:
>> It is exactly this attitude of "oh, it's so difficult" that has
>> blocked bug 164 from being fixed.
>
> Well, not really. Bug 164 would be fixed almost completely for
> Czech-language wikis by using datab
On Tue, May 12, 2009 at 4:38 PM, Brion Vibber wrote:
> * Collation use for sorting needs to be double-checked to confirm it
> wouldn't interfere with present uniqueness constraints
Since cl_sortkey isn't part of any unique key, this appears not to be
an issue for this use. Of course, it's an iss
Hoi,
Collation based on Unicode ... what do you mean by that ? Do you mean the
order of the characters in the UTF-8 or do you mean the Unicode CLDR order.
The last is the only sensible approach. The idea of the DEFAULTSORT is imho
awful; you want people to invest heavily on something that could wor
El 5/12/09 1:49 PM, Aryeh Gregor escribió:
> On Tue, May 12, 2009 at 4:38 PM, Brion Vibber wrote:
>> * Collation use for sorting needs to be double-checked to confirm it
>> wouldn't interfere with present uniqueness constraints
>
> Since cl_sortkey isn't part of any unique key, this appears not to
On Tue, May 12, 2009 at 5:46 PM, Brion Vibber wrote:
> As a general issue we also need to consider managing paging through
> collation-sorted lists, since sort keys for different inputs may produce
> the same result. At the moment I think category lists are paged by
> offset (bad!) but we should e
El 5/12/09 3:01 PM, Aryeh Gregor escribió:
> On Tue, May 12, 2009 at 5:46 PM, Brion Vibber wrote:
>> As a general issue we also need to consider managing paging through
>> collation-sorted lists, since sort keys for different inputs may produce
>> the same result. At the moment I think category li
On Tue, May 12, 2009 at 7:33 PM, Brion Vibber wrote:
> Ah, even better -- it's already broken! :)
Yup. Can be fixed without schema changes, though, at least.
> It sure is -- the first letter of each sort key entry is displayed in a
> nice large type in the category list.
Good point. That woul
Hi all,
The 'flagged revisions' bug (
https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 ) - has, by my reading
been 'reopened' for 2 weeks now. Being as this is a reasonably big deal in
the wiki scheme of things, I presume it's possible that matters are being
discussed, or otherwise moved forwa
On Tue, May 12, 2009 at 8:20 PM, private musings wrote:
> The 'flagged revisions' bug (
> https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 ) - has, by my reading
> been 'reopened' for 2 weeks now. Being as this is a reasonably big deal in
> the wiki scheme of things, I presume it's possible th
The Wikipedia Usability Initiative has extended the application deadline
for the Software Developer position till May 30th. We are recruiting
two candidates for this position. Both local applicants to the San
Francisco Bay Area and remote applicants are encouraged to apply.
Please help sprea
19 matches
Mail list logo
