[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #172 from Philippe Verdy verd...@wanadoo.fr 2010-07-22 06:00:34
UTC ---
But if the SQL engine does not have such support, this must be implemented in
the PHP code and collation keys can be stored in a new datacolumn (the extra
data column can be added or filled conditionnally : if the SQL engine
supports
the needed collations, this column can remain NULL to save storage space).
If you sort this stuff in PHP, you need to grab the entire list before you can
reliably sort it. Doing that for [[Category:Living people]] has no chance of
staying within the memory limit.
And this was false. Because you assume that the generation of sort keys has to
be done on database queries for listing the content of a category, when instead
this generation os sortkeys can be done safely only on database inserts/updates
for each separate page.
What I wanted to say is that the computed sortkeys will have to be stored. But
several sort keys for the same page in the same category are possible (one for
each collation locale indicated by the target category).
There will be no memory limit, but of course this will have a storage cost, as
the stored sort keys will have to be queried along with the list of pages to
display.
The good question to ask is: where do we store these sortkeys? Currently we
have a SQL relation table containing a unique index on (categoryID, sortkey,
pageID) and this is enough to perform the join with the table of pages. However
thre's still only one sortkey per page and per category.
That sortkey is needlessly using the pageID within the generated sortkey (this
is is visible when crossing a page limit and navigating throught pages) so in
fact the unique index is on (categoryID, augmented sortkey). Conceptually
wrong and bogous (I think this was just a fast patch when there were unicity
problems and multiple pages could be specified with the same sortkey).
What is limiting you of changing the relation table containing the list of
pages in categories, of using instead a unique index on:
(categoryID, sortkey, pageID, localeID)
where the localeID is one of the locales supported by the project, which
specifies: the language for which a collation is being performed, and a
collation variant (for example, in Chinese, sort by radical/strokes with
locale=zh-Hans, or sort by pinyin with locale=zh-Latn)
The generation of the concent of the sortkey column is the only major problem
requiring a design decision. This is where it should not even depend on the SQL
engine, and where it can be implemented within PHP, using the PHP extension
that allows using ICU functions. That string does not have to be extremely long
and does not have to be be humane readable.
It can be safely be stored with a reasonnable length limit. So ICU-generated
sortkeys are still safe if they get truncated. Notably because the unique index
on:
(categoryID, sortkey, pageID, localeID)
is also unique on its restriction:
(categoryID, pageID, localeID)
And the sortkey generated by ICU, even if it's a string of binary bytes can
still safely be stored in a table index that does not support blobs but want
only VARCHAR(n) types, by serializing the binary sortkey to a safe encoding
(the most basic that will work is hexadecimal) that does not even require the
support of Unicode or UCA collation. Just use an ASCII only column to store the
computed binary sortkey serialized as an ASCII-only string.
But if the database engine supports strings of bytes, just don't serialize the
blob, use the supported SQL type that can store it directly, for example
VARBINARY(n), if it remains sortable in binary order.
With this design, you are completely independant of the SQL engine, it will
work identically on MySQL, PostrgresSQL, or others. And you'll have solved the
problems of collation with multiple locales according to their rules, and
possibly according to visitors preferences.
Note: above, the localeID is not directly a VARCHAR(n) containing en, or
zh-Hans. It is an arbitrary unique numeric identifier that maps in fact to a
collation rule within a locale, and this collation rule may need to be updated
from time to time: when upgraded a collation, you'll generate additional keys
with a new localeID. And when this is done the table of supported collations
will indicate which localeID is the current one to use, and you'll be able to
perform easiky the cleanup of old sortkeys that where computed within the old
rule.
It's not a complicate design, and it offers stability warranties and supports
as well the possibility of upgrading the collations.
The possibility of offering multiple sortkeys for the same page in the same
category comes as a bonus, and you can assign localeID=0 to store the
user-specified sortkey that has been assigned in a page using the second
parameter of the [[category:pagename|sortkey]] link or the parameter of the
{{DEFAULTSORT:sortkey}} if this paramter was missing (this
[Bug 23293] When transcluding special page like newpages/rc/etc if any edits tagged, strip markers exposed and page title overridden
https://bugzilla.wikimedia.org/show_bug.cgi?id=23293 Bawolff bawolff...@gmail.com changed: What|Removed |Added Keywords|testme | Summary|When transcluding special |When transcluding special |page, page is rendered with |page like newpages/rc/etc |title of special page not |if any edits tagged, strip |current page|markers exposed and page ||title overridden --- Comment #7 from Bawolff bawolff...@gmail.com 2010-07-22 06:19:50 UTC --- I spent some time trying to narrow the problem down. It appears to be related to change tags, which is probably why it is intermittent (if you have special:newpages on your page, sometimes it will have tagged edits, sometimes it won't) Specifically, in my tests, commenting out the wfMsgExt( tag-$tag, 'parseinline') in ChangesTag::tagDescription (~line 31) made the issue go away, so I think thats the culprit. ( I assume this is bug 17329 ?). One fix would be to just disable showing Change tags if the special page is being transcluded. I'm not sure if there is a better fix that would both fix the issue and allow showing change tags when transcluding the special page. removing keyword testme and changing description to more fit the problem -- 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
[Bug 24478] Update default mailing list setting(s)
https://bugzilla.wikimedia.org/show_bug.cgi?id=24478 p858snake p858sn...@yahoo.com.au changed: What|Removed |Added Keywords||shell CC||p858sn...@yahoo.com.au -- 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
[Bug 23264] Dumps twisted in several languages
https://bugzilla.wikimedia.org/show_bug.cgi?id=23264 OpenTheWindows g33kd...@gmail.com changed: What|Removed |Added CC||g33kd...@gmail.com --- Comment #38 from OpenTheWindows g33kd...@gmail.com 2010-07-22 06:33:32 UTC --- simplewiki is stuck on rev 1832000, which can be fetched for me. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24433] create protection level of confirmed user sysopp in hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24433 --- Comment #10 from mayurkumar mayur...@gmail.com 2010-07-22 06:39:17 UTC --- Hi, Long Time as compared to other bugs NO reaction on this bug.I think it can be implemented now as we are requesting for creation of new protection level confirmed user sysopp in hindi wiki instead of giving protection page editing access to Confirmed User.We are grateful to bugzilla for implementing some new features in hindi wiki.But this bug is also Important for us to be resolved as soon as possible.So that we can make Our main article pages to this new protection level rather than sysopp only.And our good and experienced User may edit these pages.Our commnity hopes is bound to bugzilla and we hope this bug will be resolved as soon as possible. Thank you And sorry for inconvenience With Regards Mayur kumar -- 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
[Bug 24481] Tab Move should be visible in Vector skin - copyright issue
https://bugzilla.wikimedia.org/show_bug.cgi?id=24481 --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 06:58:30 UTC --- (In reply to comment #2) Is there any indication that this phenomenon (copypaste moves) has been getting worse since the Vector deployment? In my opinion, yes. Now people do not see this tab and they even do not know that they can drop-down menu, where exist proper option. What I meant was: is there any data that supports this notion? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24467] Simple email address
https://bugzilla.wikimedia.org/show_bug.cgi?id=24467 --- Comment #2 from Praveen Prakash me.prav...@gmail.com 2010-07-22 12:42:32 IST --- I believe current naming style extremely confusing so adding assumable email address become very usable. -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #173 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 07:15:01 UTC --- (In reply to comment #172) And this was false. Because you assume that the generation of sort keys has to be done on database queries for listing the content of a category, when instead this generation os sortkeys can be done safely only on database inserts/updates for each separate page. What I wanted to say is that the computed sortkeys will have to be stored. But several sort keys for the same page in the same category are possible (one for each collation locale indicated by the target category). [etc., etc., etc.] I suggest you read comment #171 and the wikitech-l thread linked from there. That thread is an implementation proposal by Aryeh, who, unlike pretty much everyone else commenting on this bug (myself included), is actually gonna start implementing it; he suggested he might start today. This bug already has 173 comments, and posting more long comments about hypothetical implementations while not replying to the implementation plan of the one person actually being serious about getting this done is not useful and might just push this bug to 200 comments without getting anywhere. If we're gonna discuss anything, let's discuss the current implementation plan: it is the only relevant plan to discuss at this point. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 23936] Add displaytitle to query/info API
https://bugzilla.wikimedia.org/show_bug.cgi?id=23936 Reedy s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Reedy s...@reedyboy.net 2010-07-22 08:49:09 UTC --- r67919 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24484] New: Add prop=pageprops module
https://bugzilla.wikimedia.org/show_bug.cgi?id=24484 Summary: Add prop=pageprops module Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: API AssignedTo: roan.katt...@gmail.com ReportedBy: s...@reedyboy.net CC: bryan.tongm...@gmail.com, s...@reedyboy.net, vasi...@gmail.com, soxre...@gmail.com As above -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24485] New: Make iwbacklinks a generator, display iwprefix and iwtitle optionally
https://bugzilla.wikimedia.org/show_bug.cgi?id=24485 Summary: Make iwbacklinks a generator, display iwprefix and iwtitle optionally Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: API AssignedTo: s...@reedyboy.net ReportedBy: s...@reedyboy.net CC: bryan.tongm...@gmail.com, s...@reedyboy.net, roan.katt...@gmail.com, vasi...@gmail.com, soxre...@gmail.com RoanKattouw Reedy: Two TODOs for you for after I commit, I'm almost finished: iwbacklinks should be a generator and should (optionally?) display iwprefix and iwtitle as well in case you're not querying a specific iw title but a broad prefix or everything Followup to r69721 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24484] Add prop=pageprops module
https://bugzilla.wikimedia.org/show_bug.cgi?id=24484 --- Comment #1 from Reedy s...@reedyboy.net 2010-07-22 09:07:41 UTC --- Reedy Also, for the page props, there's going to be no way to say these are all the possible properties is there? As I guess it's not stored... Reedy Unless we add more globals (ugh..) and let extensions register any they may add, aswell as doing the core ones somewhere... RoanKattouw No, those aren't being registered Bryan you can also make it a parser static variable is you don't want to use a global :) Bryan or even an instance variable ^ something to be thought about -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #174 from Philippe Verdy verd...@wanadoo.fr 2010-07-22 09:13:30
UTC ---
If we're gonna discuss anything, let's
discuss the current implementation plan: it is the only relevant plan to
discuss at this point.
This is EXACTLY what I was discussing: proposing an implementation design,
which also considers the fact that collations will also need to evolve over
time (for example the UCS repertoire is evolving (so the DUCET table is
modified), and collation rules are being corrected for some languages, in the
CLDR project) : each change will generate a new internal localeid to support
it, and there will be possibly different keys during the transition, even if
(finally) an old collation rule will be deleted (with its old sortkeys) after
the new sortkeys will have been fully recomputed.
So this is clearly not blah blah. And this is certainly relevant for the fact
that you're considering implementing some or all of the suggestions (and you'll
have to test your solutions, including on their performance impact.
I propose a simple model that can be very space-efficient, and that also avoids
reparsing all pages if ever a collation rule is changed, or if additional
collation rules are added in a category to support multiple sort orders
(notably within Chinese categories that could support different orders).
My proposal does not even depend on the backend SQL server capabilities (all it
has to support is at least a binary order on ASCII-only VARCHAR(n) to store the
computed and truncated sortkeys, that will be generated by the PHP front-end
(using ICU) and followed by an ASCII-only serialization. This means that the
simplest ORDER BY queries to retrieve correctly ordered lists of pages will
work independantly of the backend.
The function used in PHP to generate the binary-ordered sortkey (that will
finally be effectively stored) should also be accessible in MediaWiki as a
builtin parser function, that will take two parameters: the locale code, and
the text.
For example, as {{SORTKEY:text|locale}}, where the ''locale'' specified can be
optional and will take the default value of the {{CONTENTLANGUAGE}} of the
project).
This builtin parser function could also be used to correctly sort the sortable
Mediawiki tables inserted in articles, by using correct sortkeys generated by
this template, if the generated sortkey is readable and effectively serialized
as ASCII-only, but it does not necessarily have to be truncated by this
function, even if it will be truncated when the same function result will be
used to store sortkeys in the schema).
This parser function should even be the first development to realize, before
even changing the category-page indexes, because it can be applied and tested
immediately in existing categories (for example by using categorizing templates
in Wiktionary), without even upgrading the SQL schema.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
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
[Bug 24486] New: Create Appendix namespace on the Luxembourgish Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=24486 Summary: Create Appendix namespace on the Luxembourgish Wiktionary Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: arjanverheij...@hotmail.com Hello, could some please create two new namespaces on lb.wiktionary.org? We need Annexen (appendix) and Annexen Diskussioun (appendix discussion). I don't know what the namespace numbers are, but I suspected it would be something like this: ns:17 - Annexen ns:18 - Annexen Diskussioun Thanks in advantage :) Arjan Verheijden ([[:wikt:lb:Benotzer:Ooswesthoesbes]]) -- 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
[Bug 24486] Create Appendix namespace on the Luxembourgish Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=24486 p858snake p858sn...@yahoo.com.au changed: What|Removed |Added Keywords||shell CC||p858sn...@yahoo.com.au --- Comment #1 from p858snake p858sn...@yahoo.com.au 2010-07-22 09:32:58 UTC --- Please show a link to community consensus for this change. -- 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
[Bug 24486] Create Appendix namespace on the Luxembourgish Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=24486 --- Comment #2 from Arjan Verheijden arjanverheij...@hotmail.com 2010-07-22 09:39:08 UTC --- See: http://lb.wiktionary.org/wiki/Wiktionary:De_Staminee#New%20namespace and http://lb.wiktionary.org/w/index.php?title=Benotzer_Diskussioun:Ooswesthoesbescurid=2239diff=4919oldid=4912. -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #175 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 09:59:32 UTC --- (In reply to comment #174) If we're gonna discuss anything, let's discuss the current implementation plan: it is the only relevant plan to discuss at this point. This is EXACTLY what I was discussing: proposing an implementation design, AFAICT you're proposing your own design without mentioning where it differs from or coincides with Aryeh's proposal. From briefly reading your latest comment, it looks like a lot of what you're proposing is already in Aryeh's proposal, such as the binary-ordered sortkey thing. Other things, such as the attention you're paying to the possibility that collation rules may change, are not covered in Aryeh's proposal, so those are valuable additions. So you're right, it's certainly not blah blah, but it would help a lot if you limited your comments to the differences between your and Aryeh's proposal, rather than leaving it up to the reader to find and filter the parts the two proposals have in common. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24486] Create Appendix namespace on the Luxembourgish Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=24486 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com AssignedTo|wikibug...@lists.wikimedia. |rhals...@wikimedia.org |org | --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 10:00:56 UTC --- (In reply to comment #0) ns:17 - Annexen ns:18 - Annexen Diskussioun Custom namespaces have numbers starting at 100. Also, subject namespaces have even numbers and talk namespaces have odd numbers. -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #176 from Philippe Verdy verd...@wanadoo.fr 2010-07-22 10:04:53
UTC ---
Anyway, the Aryeh's proposal is not found or documented at the location you
indicate. It just says that he will try to work on it today and still asks for
solutions and asks for questions that are unanswered in his comment on the
wikitech-l list.
In a similar spirit, the generation of the section heading for categories could
also be a different builtin parser function such as:
: {{COLLATIONMAP:text|locale|level|clusters}}
with the similar parameters, and clusters=1 be default (more below). It will
return a non-opaque string that can be displayed in category pages, and could
even become a valid anchor for searching starting at some text position in the
list (ordered using the specified locale). It should be only a level-1
collation mapping by default (only level 1 will be considered for displaying
headings, however some categories could later specify another default collation
level for such mapping.
Note that collation-based mappings is a VERY different concept from the concept
of collation-based sortkeys (read the Unicode UCA specification): sortkeys are
opaque and intended to generate a full order of texts, mappings are readable
but only intended to produce a partial order.
Another optional parameter could be given after the collation level, to
indicate how many locale grapheme clusters should be included in the heading.
The default
headings in categories should just use 1 grapheme cluster from the text given
to the first parameter of {{COLLATIONMAP:text|locale|level|clusters}} (more
below).
In a category you could *LATER* specify additional sort orders (and collation
mappings at the same time) using a syntax like:
{{SORTORDER:locale|level}} (the default collation level will be 1 for
categories).
Example 1: in a Chinese category page, you could specify:
; {{SORTORDER:zh-hans}}
: to indicate that pages in that category will be also available using the
radical/stroke order of sinograms.
; {{SORTORDER:zh-latn}}
: to indicate that pages in that category will be also available using the
Pinyin Latin order.
Example 2: in a Korean cateogry, where the primary order is based on the
decomposition into jamos, it will be enough to specify:
; {{SORTORDER:ko}}
: (for the default South Korean order of jamos)
; {{SORTORDER:ko-kp}}
: (for the default North Korean order of jamos)
Indicating the collation level with a value different from 1 could generate sub
headings for level 2, but I think it should only display them with the
specified level, all using the same heading from the level-2 collation mapping.
Indicating clusters=2 (or more) in the builtin parserfunction {{COLLATIONMAP:}}
may be used to generate more precise headings (for example in heavily English
or French populated categories, use 2 grapheme clusters to generate headings on
the 2 first letters, but keep the collation level to 1). By default the builtin
parser function will not limit the number of grapheme clusters (so it will
remap all the text), but a category could still specify this maximum number of
clusters to consider for headings.
By default a category will consider either
* clusters=1 : section headings will be generated only for the first cluster
(this is what is currently used in categories). or
* clusters=0 : section headings will not be generated at all.
(this default could be a per-project default).
The generation of section headings (using the same PHP function used by
{{COLLATIONMAP:}}) does not require any modification of the schema. Headings
can be computed and generated on the fly, from the retrieved list of pages.
Headings should not even influence the sort order, they are just convenient
groupings for display.
The {{COLLATIONMAP:}} function described here would in fact enter in the list
of string builtin function, as it falls in the same category as other mapping
functions like {{UC:}} or {{LC:}}. This is just another mapping.
The generation of sort keys (using the same PHP function used by {{SORTKEY:}})
however requires active parsing to store them in the schema. So it can only be
done later. This developement should be made *later* (when the SQL schema for
category indexes will be adjusted to support multiple/upgradable collation
orders).
So yes, a builtin parser function such as
{{COLLATIONMAP:text|locale|level|clusters should first be implemented and
tested separately before being used to group items in category headings, but it
can be implemented separately from the developement and deployment of the SQL
schema for indexing categories with {{SORTKEY:}}), and integrated later in the
code that will present the list of pages to the users.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
[Bug 24487] New: Need for new contributions list
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 Summary: Need for new contributions list Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: bpkserv...@mail.ru * URL: [http://ru.wikipedia.org Wikipedia] Hello. I'm writing about Wikipedia at all, not the Russian one only. Many people, I came in contact with, and me too, consider that the current contributions list format is inconvenient. I do not need to know all the versions of articles edited by me (i.e. many lines for one article), but need for the list where are titles of articles I've ever edited (no time restriction) - '''one line per article strictly''', no more, and the mark which shows, whether my version is the most recent. Nothing more. Is it possible to do so with the MediaWiki version used in Wikipedia? (sorry, I couldn't figure out how to find the version number). -- 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
[Bug 24487] Need for new contributions list
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 --- Comment #1 from Reedy s...@reedyboy.net 2010-07-22 10:06:21 UTC --- So you just want a unique list of all pages ever edited? -- 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
[Bug 24487] Need for new contributions list
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 bpkserv...@mail.ru changed: What|Removed |Added URL||http://ru.wikipedia.org -- 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
[Bug 24487] Need for new contributions list
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 --- Comment #2 from bpkserv...@mail.ru 2010-07-22 10:09:17 UTC --- (In reply to comment #1) So you just want a unique list of all pages ever edited? Yes. And, if possible, not JavaScript-driven. -- 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
[Bug 24488] New: Don't encourage users to insert deprecated presentational tags by presence of such buttons on edit toolbar
https://bugzilla.wikimedia.org/show_bug.cgi?id=24488 Summary: Don't encourage users to insert deprecated presentational tags by presence of such buttons on edit toolbar Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: dann...@email.cz CC: roan.katt...@gmail.com, ngau...@wikimedia.org, amil...@wikimedia.org The edit toolbar should not contain buttons which insert deprecated presentational tags, such as big or small, which encourage users to use them, although they should not. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24489] New: Remove the Indentation button from edit toolbar
https://bugzilla.wikimedia.org/show_bug.cgi?id=24489 Summary: Remove the Indentation button from edit toolbar Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: dann...@email.cz CC: roan.katt...@gmail.com, ngau...@wikimedia.org, amil...@wikimedia.org Since there is no wikitext markup for indentation, but dd of dl is being hugely abused instead (see bug 4521), the Indentation button - which does not insert indentation but definition - should be removed from edit toolbar until proper solution for indentation is implemented. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24486] Create Appendix namespace on the Luxembourgish Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=24486 --- Comment #4 from Arjan Verheijden arjanverheij...@hotmail.com 2010-07-22 10:11:33 UTC --- Then it would be ns:100 - Annexen ns:101 - Annexen Diskussioun I think :) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24490] New: Exhibit - Do not show Empty Facets
https://bugzilla.wikimedia.org/show_bug.cgi?id=24490 Summary: Exhibit - Do not show Empty Facets Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: SemanticResultFormats AssignedTo: denny.vrande...@kit.edu ReportedBy: mitchell_ne...@hotmail.com CC: wikibugs-l@lists.wikimedia.org Hi. At the moment if a defined facet does not return any values, exhibit displays an empty filter box on the right. It would be great if a filter box does not show if the associated facet has no results. Thanks Neill. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24487] Need for new contributions list
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 p858snake p858sn...@yahoo.com.au changed: What|Removed |Added CC||p858sn...@yahoo.com.au Component|User interface |Extensions requests Version|unspecified |any Product|MediaWiki |MediaWiki extensions --- Comment #3 from p858snake p858sn...@yahoo.com.au 2010-07-22 10:13:31 UTC --- This would probably be best done as a extension. -- 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
[Bug 24488] Don't encourage users to insert deprecated presentational tags by presence of such buttons on edit toolbar
https://bugzilla.wikimedia.org/show_bug.cgi?id=24488 p858snake p858sn...@yahoo.com.au changed: What|Removed |Added CC||p858sn...@yahoo.com.au --- Comment #1 from p858snake p858sn...@yahoo.com.au 2010-07-22 10:14:16 UTC --- Um, were they ever actually part of the html specs, i thought we just made up the Big and Small? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #177 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 10:17:54 UTC --- (In reply to comment #176) Anyway, the Aryeh's proposal is not found or documented at the location you indicate. It just says that he will try to work on it today and still asks for solutions and asks for questions that are unanswered in his comment on the wikitech-l list. He does document a fair bit of what he wants to do (e.g. separating files, categories and regular pages with sortkey prefixes). It's not a complete proposal and he is asking for input, but he hasn't left everything open either. Also, why keep the discussion in two places? Why not join the discussion on wikitech-l? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24487] List distinct articles edited by a user
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com Summary|Need for new contributions |List distinct articles |list|edited by a user -- 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
[Bug 24487] List distinct articles edited by a user
https://bugzilla.wikimedia.org/show_bug.cgi?id=24487 --- Comment #4 from bpkserv...@mail.ru 2010-07-22 10:19:10 UTC --- (In reply to comment #3) This would probably be best done as a extension. I am not a specialist. Just an user. -- 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
[Bug 24488] Don't encourage users to insert deprecated presentational tags by presence of such buttons on edit toolbar
https://bugzilla.wikimedia.org/show_bug.cgi?id=24488 --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 10:21:06 UTC --- (In reply to comment #1) Um, were they ever actually part of the html specs, i thought we just made up the Big and Small? No, we didn't make them up, they're HTML tags. Look at the HTML output of previewing bigfoo/big and you'll see it's really just bigfoo/big -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #178 from Philippe Verdy verd...@wanadoo.fr 2010-07-22 10:48:39
UTC ---
Because his specification is really incomplete, and he said that Bug#164 was
useless (despite of the fact that I had described my solution extensively in
Bug#164long before Ariyeh started working on it.
And yes, before ever attempting to change the schema, I support the prior
developement and extensive testing of builtin parser functions supported by PHP
functions which will be shared later to support the updated SQL schema.
Only this developmeent alone will have significant difficulties:
* notably integrating ICU in a PHP module installation, or
* rewriting the collation algorithms entirely with PHP;
* having to support the DUCET updates caused by new Unicode versions or
corrections;
* having to support multiple collation orders by per-locale tailorizations
(coming from CLDR or from other sources).
The need to support upgraded collation orders is also an important decision
factor for the schema, if sortkeys are stored in a SQL backend, that's why I
speak about it very early:
* collations supported by SQL backends have very strong limitations, or any
upgrade would require shutting down the servers for hours or days to perform
the upgrade of collated indexes.
* in their missing full ISO 10646 level 3 implementation for the support of
supplementary planes.
All this is something that can be avoided completely by using ICU and not
depending on SQL backends for their support of many more collation locales that
we need in our international projects:
* the schema just needs to be able to store multiple sortkeys, so that newer
sortkeys (computed with the new rules) can be progressively computed in the
background by a bot or server script or some upgrades occuring on the fly when
processing articles.
* older sortkeys that were using a older generation rule can be deleted in a
simple DELETE operation after the new collation rule for a corrected locale has
been made the default one, or can be deleted one by one each time a new
generation sortkey is recomputed and has been inserted (there's not even the
need to perform the two sucessive operations in a transaction if the first
INSERT withe the new rule has been sucessful).
Because we have now multiple sortkeys per indexed page in a category, we can
conveniently support multiple sortkeys for different locales and offer a good
experience for users that will want alternate sort orders (notably Chinese
users that will want presentations in radical/stroke order, or in pinyin
order).
Another note about how to serialize the opaque sortkeys:
the builtin function {{SORTKEY:text|locale|level}} described above will not
limit the length of the generated binary sortkey, however it should serilize it
in a valid Unicode text that can be used in tables.
A convenient serialization of bytes to characters that will sort correctly is
Base-36 using the alphabet [0-9A-Z] (no padding necessary) or Base-32 (it
avoids modular arithmetics but will serialize into longer strings)
If sortkeys are about to be stored, retrieved in the SQL schema, and sorted by
the SQL clause ORDER BY...sortkey..., then:
- either the SQL backend allows storing and sorting binary sequences of bytes
as VARBINARY(N) : then no extra serialization is needed, store directly that
opaque sort key, after truncation to the max length value (N) indicated in the
SQL type of the sortkey table column.
- or the SQL backend does not support sortable binary sequences of arbitrary
bytes, but can only sort VARCHAR(N), then use a similar Base-32 or Base-36
conversion to create compatible sortkeys, and then store the converted string
after truncating to the max length value (N) indicated in the SQL type of the
'sortkey table column.
- in both cases, the stored sortkeys will NEVER be exposed to users, its sole
purpose is to make the SQL ORDER BY clause work properly.
To start listing a category from a given artbitrary Unicode text, use the
start= HTTP query parameter and compute internally the sortkey associated
with it to generate the value used in SQL clause WHERE sortkey = 'value'.
- Section headings in categories will never need to be stored, they are
generated on the fly by reading the page names retrieved in the SQL result set
using the {{COLLATIONMAP:}} function, with the specified locale in the
uselang= HTTP query parameters, and the specified (or default) clusters=
parameter (whose default will be 1 or 0 as indicated above). They will be
diretly readable by users and do not require decoding anything from the stored
sortkey.
- the readable collation mappings and the opaque sortkeys should be coherent in
the same locale, but they are clearly different: pagenames that are
collation-mapped should sort in the same natural order as the section headings
generated from them, so it's absolutely not needed to generate sort keys from
collation-ampped headings computed in the fly.
--
[Bug 24491] New: Users shouldn't be given Upload a new version of this file when a file is protected
https://bugzilla.wikimedia.org/show_bug.cgi?id=24491 Summary: Users shouldn't be given Upload a new version of this file when a file is protected Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Page protection AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: liang...@gmail.com Or they may spend some time on editing these files only to find their better images can only stay in their hard disk. -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #179 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 11:16:18
UTC ---
(In reply to comment #178)
All this is something that can be avoided completely by using ICU and not
depending on SQL backends for their support of many more collation locales
This is exactly what Aryeh is proposing. I think everyone agrees that it's
better to use binary sorting with munged sortkeys rather than SQL backends'
half-baked collation support, so you don't need to argue that.
- Section headings in categories will never need to be stored, they are
generated on the fly by reading the page names retrieved in the SQL result set
using the {{COLLATIONMAP:}} function, with the specified locale in the
uselang= HTTP query parameters, and the specified (or default) clusters=
parameter (whose default will be 1 or 0 as indicated above). They will be
diretly readable by users and do not require decoding anything from the stored
sortkey.
This is not that simple, as was pointed out on wikitech-l: what if you've got a
language where á sorts the same as a (that is, a and á are the same for sorting
purposes), then your sorted result could look like:
Áa
Áb
Ac
Ád
Ae
Af
Ág
...
We humans understand that the proper heading for this is A, not Á, but how
will the software know that? Even if we store the original, unmunged sortkeys
(note that the sortkey is not necessarily equal to the page name: [[Albert
Einstein]] sorts as Einstein, Albert) so we can differentiate A from Á, we
can't just take the first or even the most frequent letter: neither is accurate
in this case.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
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
[Bug 24492] New: Long thread titles overlap with thread buttons
https://bugzilla.wikimedia.org/show_bug.cgi?id=24492 Summary: Long thread titles overlap with thread buttons Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: LiquidThreads AssignedTo: agarr...@wikimedia.org ReportedBy: federicol...@tiscali.it Created an attachment (id=7580) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=7580) Thread with long title See attachment ([[Special:NewMessages]] on strategy wiki). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 20139] CSS error in combined.min.css
https://bugzilla.wikimedia.org/show_bug.cgi?id=20139 Danny B. dann...@email.cz changed: What|Removed |Added CC||dann...@email.cz Blocks||12788 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 12788] CSS (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=12788 Danny B. dann...@email.cz changed: What|Removed |Added Depends on||20139 -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #180 from Philippe Verdy verd...@wanadoo.fr 2010-07-22 11:42:55
UTC ---
Your issue ***IS*** addressed in my proposal:
*Both* {{COLLATIONMAP:Áa}} and {{COLLATIONMAP:Aa}} will be unambiguously aa
in the primary collation level for that locale. They only differ at the
secondary collation level (with accents).
You did not understand that a collation-mapping is DIFFERENT from an opaque
sort key, even if both are built using the same collation rules for the same
locale.
The case of Albert Einstein sorting as Einstein, Albert will pass through
the standard generation of the sortkey from the string Einstein, Albert
explicitly given in MediaWiki source code as the parameter of the
{{DEFAULTSORT:Einstein, Albert}} special function or as the second parameter of
the [[category:...|Einstein, Albert]] link.
So here is a development and deployment map:
1) Develop to PHP functions that will compute:
function sortkey($text, $locale, $level=1)
- it will return an opaque array of byte values
- $locale may be given a default value from the project's content language,
but this is not specified here but part of its integration in MediaWiki
- $level may take the default value of 1.
- the algorithm involves parsing steps to transform the $text parameter
into normalized form, then parse it by collation element, and then locating the
collation element in the tailored collation table, which is indexed by
collation element value and returns an array of collation weights, one for each
level.
- it packs all the collation weights into the returned opaque array of byte
values, by appaending all non-zero collation weights for each collation element
at the same collation level before appending the collation weights for higher
successive levels.
function collationmap($text, $locale, $level=1, $clusters)
- it will return a remapped text using the same $locale and $level
parameters
- it will use the same DUCET table and the same per-locale tailorings
- the same parsing steps are performed
- but instead of packing the collation weigths, it scans the collation
table in the reverse order, by locating the first collation element (a small
Unicode string, often limited to a single character) that has the same
collation weights up to the specified level. When this smallest collation
element is found, append this to the result string.
function base36($bytes)
- it packs the opaque binary array of bytes into plain ASCII that has safe
binary order and can be safely be stored in a VARCHAR(N) table field, or that
can be returned in a MediaWiki function.
This module should use ICU and implement the locale tailorings, and should be
able to support a full DUCET table,and allow lookups from a collation element
to an array of collation weights, or the reverse (and ordered) lookup from a
collation weight to a collation element for the function collationmap())
2) Integrate these functions in a Media Wiki extension for builtin parser
functions.
{{SORTKEY:text|locale|level}}
- this will return base36(sortkey($text, $locale, $level))
- by default take $level=1
- by default take $locale={{CONTENTLANGUAGE}} (or {{int:lang}} ?)
- it can be used as a much better implementation of Wikipedia templates
like [[Template:Sort]]
{{COLLATIONMAP:text|locale|level|clusters}}
- this will return collationmap($text, $locale, $level, $clusters)
- it can be used to simulate the generation of headings in categories, but
as well within mediawiki tables
- by default take $clusters=null (no limitation of length)
- by default take $level=1
- by default take $locale={{CONTENTLANGUAGE}} (or {{int:lang}} ?)
3) build a function for mapping category sortkeys into stored sort keys, this
will depend on the SQL backend capabilities and on the schema constraint length
for the sortkey data columns:
function sqlsortkey($text, $locale, $level)
- it will return either :
substring(sortkey($text, $locale, $level), 0, $maxlength)
- or :
substring(base36(sortkey($text, $locale, $level)), 0, $maxlength)
- the choice will depend on the support of VARBINARY(N) and its
sortability in the SQL engine, or of only VARCHAR(N)
- the sortkey will not have to be UTF-8, and will not need any support of
the same locales for collation tailoring in the SQL backend.
4) update the schema to support the description of supported internal collation
ids.
- add a mapping function from the human readable $locale parameter to the
collation id associated to the curent version of the collation rule currently
applicable to a locale.
- support this mapping with a simple collations relational table
5) build a new category index based on:
(categoryid, collationid, sortkey, pageid)
- categoryid and pageid are standard MediaWiki page ids (in any modification
version).
- collationid will come from the previous
[Bug 24494] New: 404 error (File not found) when clicking from Special:NewMessages the header/title of a thread marked as read with some unescaped characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=24494 Summary: 404 error (File not found) when clicking from Special:NewMessages the header/title of a thread marked as read with some unescaped characters Product: MediaWiki extensions Version: any Platform: All URL: http://strategy.wikimedia.org/wiki/Thread%3AUser%20tal k%3APhilippe%20%28WMF%29%2FTypo%20in%20the%20side-wide %20template OS/Version: All Status: NEW Severity: normal Priority: Normal Component: LiquidThreads AssignedTo: agarr...@wikimedia.org ReportedBy: federicol...@tiscali.it Well, actually I don't know what's causing the problem, anyway whatever thread on Philippe's talk I mark as read on strategy wiki's Special:NewMessages can't be reached by clicking his title/header/link (e.g. «The thread Typo in the side-wide template was marked as read. Undo»), I suppose because of that (WMF) in the user name: spaces and brackets are not escaped (they are automatically bu the URL text area in this bug, but they are not in the browser, see attachment). Note that the full thread link provided before marking the thread as read does work (http://strategy.wikimedia.org/w/index.php?title=User_talk:Philippe_%28WMF%29offset=20100201214836#Typo_in_the_side-wide_template_3470 ). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24494] 404 error (File not found) when clicking from Special:NewMessages the header/title of a thread marked as read with some unescaped characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=24494 --- Comment #1 from Nemo_bis federicol...@tiscali.it 2010-07-22 14:29:13 CEST --- Created an attachment (id=7581) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=7581) 404 error -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24494] 404 error (File not found) when clicking from Special:NewMessages the header/title of a thread marked as read with some unescaped characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=24494 --- Comment #2 from Nemo_bis federicol...@tiscali.it 2010-07-22 14:29:53 CEST --- Created an attachment (id=7582) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=7582) The broken link (look at the status bar) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24495] New: Images for sub and sup are confusing on enhanced toolbar.
https://bugzilla.wikimedia.org/show_bug.cgi?id=24495 Summary: Images for sub and sup are confusing on enhanced toolbar. Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: trivial Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: dann...@email.cz CC: roan.katt...@gmail.com, ngau...@wikimedia.org, amil...@wikimedia.org Blocks: 24493 Although there are A+ and A- buttons aside, A^ and Av buttons are confusing - they rather imply changing of font size than inserting sup/sub. Images like http://upload.wikimedia.org/wikipedia/commons/6/6a/Button_sup_letter.png and http://upload.wikimedia.org/wikipedia/commons/a/aa/Button_sub_letter.png should be used instead where the X should be normal and 2 bolded to emphasize the important part of the image. Such images are common in random editors so people are used to them rather than to those there now. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24493] Enhanced toolbar issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=24493 Danny B. dann...@email.cz changed: What|Removed |Added Depends on||24495 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 21688] Overlapping header and links
https://bugzilla.wikimedia.org/show_bug.cgi?id=21688 Nemo_bis federicol...@tiscali.it changed: What|Removed |Added CC||federicol...@tiscali.it Summary|Operlapping header and |Overlapping header and |links |links -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #182 from Philippe Verdy verd...@wanadoo.fr 2010-07-22 13:18:28
UTC ---
Note that my developement plan will NOT imply an immmediate change of the SQL
schema. At first, if only working on the frist 2 steps, no schema change is
necessary to effectively test the two functions.
Notably, you'll be able to create test pages containing lists of words
formatted as table rows using a template. You'll be able to show the words, in
one column, then the opaque (base-36 converted) sort keys in another column,
and then the visible collation-mapped string in a third column.
Then you'll include this list within a page adding the table headers and using
the existing sortable table class to see how they collate when sorting by the
second column, and you'll also be able to sort again on the third column, to
see that the collation-mapped string will not alter this sort order.
If all this passes, this can be deployed and immediately used in Wiktionnary
(notably French Wiktionnary) for sorting categories containing huge lists of
words, or in english Wiktionnary for use in the template that generate sort
keys for people's Last name, first name.
This will be already a considerable progress, even if there will be no
immediate support for multiple sort orders (in Chinese).
The change of schema, where the {{defaultsort:sortkey}} parameter or the second
parameter of the [[category:page|sortkey]] link will be used effectively, so
that we no longer have to use a sortkey parameter in pages and templates can be
delayed a lot.
But the two developed functions (at least the first one
{{SORTKEY:text|locale|level}} which is a bit simpler to implement than the
second one {{COLLATIONMAP:text|locale|level}} that is a bit trickier as it
requires special handling for collation elements that are mapped to more than 1
collation weight per level) should be a lot simplified, and will be enough
tested before even thinking about reusing them for sorting pages in categories
and presenting the lists with headings.
There is a separate modification to develop for grouping category contents by
namespace. This should be developed and deployed first before even trying to
change the schema for sort keys.
In fact, the first integration for displaying categories will be to use
{{COLLATIONMAP:}} internally for displaying the headings in category pages.
This won't require any change as well for the SQL schema.
Finally, the use of {{SORTKEY:}} and the addition of new keywords for use in
category pages, that will allow a category to support multiple collations, will
happen only at the last step. Because this is the most sensitive one and this
is the only step that may finally involve a change of schema. There's much
enough work to do for building all the first integration steps, as extensive
tests in various locales will be needed, so that all wikis report their
problems with the implemented collations and their supported tailorings.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
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
[Bug 24492] Long thread titles overlap with thread buttons
https://bugzilla.wikimedia.org/show_bug.cgi?id=24492 Nemo_bis federicol...@tiscali.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Nemo_bis federicol...@tiscali.it 2010-07-22 15:19:11 CEST --- *** This bug has been marked as a duplicate of bug 21531 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 21531] LiquidThreads thread titles obscured by thread action links
https://bugzilla.wikimedia.org/show_bug.cgi?id=21531 Nemo_bis federicol...@tiscali.it changed: What|Removed |Added CC||federicol...@tiscali.it --- Comment #6 from Nemo_bis federicol...@tiscali.it 2010-07-22 15:19:11 CEST --- *** Bug 24492 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24496] New: UniversalEditButton
https://bugzilla.wikimedia.org/show_bug.cgi?id=24496 Summary: UniversalEditButton Product: MediaWiki Version: 1.16 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Installation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: mediaw...@kghoffmeyer.de So far an wiki administrator has to insert $wgUniversalEditButton = true; into LocalSettings.php in order to activate the Universal Edit Button for browsers that support it. I think it would be good if an wiki administrator gets asked during the installing process, if it should be activated or not. -- 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
[Bug 24497] New: When editing header, the header tab should be edit header on monobook to be clear
https://bugzilla.wikimedia.org/show_bug.cgi?id=24497 Summary: When editing header, the header tab should be edit header on monobook to be clear Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: LiquidThreads AssignedTo: agarr...@wikimedia.org ReportedBy: federicol...@tiscali.it Created an attachment (id=7583) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=7583) Editing header section on monobook: the link shown in the status bar isn't the one actually shown before screenshot On monobook, when you edit a talk page header a new tab header appears after watch/unwatch (?), and it links to the editing of the whole header instead of the header itself (which is discussion tab). The tab should be like in every page i.e. edit (or if not possible edit header) immediately after discussion. Indeed, it would be useful to have also the usual history tab/link, currently available only with the history button at the bottom of the header (as well as the edit button), which can be very annoying on threads which have been switched to LT. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24497] When editing header, the header tab should be edit header on monobook to be clear
https://bugzilla.wikimedia.org/show_bug.cgi?id=24497 --- Comment #1 from Nemo_bis federicol...@tiscali.it 2010-07-22 15:33:07 CEST --- Created an attachment (id=7584) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=7584) Editing header on Vector -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24497] When editing header, the header tab should be edit header on monobook to be clear
https://bugzilla.wikimedia.org/show_bug.cgi?id=24497 Nemo_bis federicol...@tiscali.it changed: What|Removed |Added Attachment #7584|Editing header on Vector|Editing header on Vector: description||still no history button -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24473] Wrong To header field in account request ConfirmAccountContact
https://bugzilla.wikimedia.org/show_bug.cgi?id=24473 Alessandro Vesely ves...@tana.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Alessandro Vesely ves...@tana.it 2010-07-22 15:24:49 UTC --- (In reply to comment #1) The prompt that a user confirmed their email address? Yes, that one. However, I've downloaded the 1.15.x snapshot, which is quite old. Now I've browsed the trunk version, and the code there is different. It seems this bug has been fixed in r64418 on Wed Mar 31 02:45:29 2010 UTC Cleaned up confirmEmailToken() email handling a bit. So I change status to FIXED. I probably should have installed the trunk version, but the extension's page says Select the snapshot for your version of MediaWiki. I'm not familiar with MW version changes, and thought bug fixes had been committed backward. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 23932] Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, dialog, figure, footer, header, hgroup, mark, nav, section, time
https://bugzilla.wikimedia.org/show_bug.cgi?id=23932 --- Comment #4 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-07-22 15:52:51 UTC --- No, we only kowtow to them until they're not used by a significant number of people. The number of users using IE = 8 with JS disabled must be negligible before we do this, because it will break pages for them. -- 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
[Bug 24498] New: SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 Summary: SimpleSearch: Regression: Cannot drop text in the search box Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: liang...@gmail.com CC: roan.katt...@gmail.com, ngau...@wikimedia.org, amil...@wikimedia.org When I drag some text and drop it in the search box, it becomes gray and stays around the word 'Search'. If I try to remove the word 'Search' and click on the box, the text I dropped just now disappears. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 Derk-Jan Hartman hart...@videolan.org changed: What|Removed |Added CC||hart...@videolan.org --- Comment #1 from Derk-Jan Hartman hart...@videolan.org 2010-07-22 17:55:40 CEST --- Please specify which browser (+version) you are using. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 --- Comment #2 from Liangent liang...@gmail.com 2010-07-22 15:56:32 UTC --- (In reply to comment #1) Please specify which browser (+version) you are using. Iceweasel 3.5.8 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24491] Users shouldn't be given Upload a new version of this file when a file is protected
https://bugzilla.wikimedia.org/show_bug.cgi?id=24491 Derk-Jan Hartman hart...@videolan.org changed: What|Removed |Added CC||gpaum...@wikimedia.org --- Comment #1 from Derk-Jan Hartman hart...@videolan.org 2010-07-22 18:02:30 CEST --- Though in principal I agree, hiding elements in general causes confusion... where did this option go. Adding guillom to CC, since he might have an opinion on this from the Multimedia usability project side. -- 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
[Bug 23932] Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, dialog, figure, footer, header, hgroup, mark, nav, section, time
https://bugzilla.wikimedia.org/show_bug.cgi?id=23932 --- Comment #5 from Michael Zajac mich...@zajac.ca 2010-07-22 11:07:24 CDT --- Negligible number of users of what, Aryeh? Users where? Isn't that a decision for a site's administrator? If Azerbaijani Wikicorduroys has no MSIE users at all, then its administrators could choose to use this feature. But only if it is added to the software first. -- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 --- Comment #3 from AlexSm ale...@b.smotrov.com 2010-07-22 16:17:41 UTC --- The same thing happens in FireFox 3.6.7 and IE8: label search prevents text drag-and-dropping. The workaround is to remove the label by inserting e.g. one space into the search field. Google Chrome works ok; Opera 10.60 doesn't seem to have this feature at all. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 Derk-Jan Hartman hart...@videolan.org changed: What|Removed |Added Severity|enhancement |minor -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 --- Comment #4 from Liangent liang...@gmail.com 2010-07-22 16:31:49 UTC --- This may be due to an attempt to fix bug 24096. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24096] Right click on the word Search
https://bugzilla.wikimedia.org/show_bug.cgi?id=24096 --- Comment #5 from Liangent liang...@gmail.com 2010-07-22 16:34:32 UTC --- See also bug 24498. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24096] Right click on the word Search
https://bugzilla.wikimedia.org/show_bug.cgi?id=24096 Liangent liang...@gmail.com changed: What|Removed |Added CC||amil...@wikimedia.org, ||ngau...@wikimedia.org Component|Vector Skin |UsabilityInitiative Version|unspecified |any AssignedTo|amil...@wikimedia.org |tpars...@wikimedia.org Product|MediaWiki |MediaWiki extensions -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 --- Comment #5 from Derk-Jan Hartman hart...@videolan.org 2010-07-22 18:44:37 CEST --- If only all browsers supported HTML5 yet, then this would be so much easier :D http://dev.w3.org/html5/spec/Overview.html#the-placeholder-attribute -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 Adam Miller amil...@wikimedia.org changed: What|Removed |Added AssignedTo|tpars...@wikimedia.org |amil...@wikimedia.org --- Comment #6 from Adam Miller amil...@wikimedia.org 2010-07-22 16:49:09 UTC --- I think we had code in place to deal with drag/drop before...I'll see what I can come up with. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 16690] bewildering bold message on [[Special:Preferences]] of SUL accounts
https://bugzilla.wikimedia.org/show_bug.cgi?id=16690 Lewis Cawte lewisca...@hotmail.co.uk changed: What|Removed |Added CC||lewisca...@hotmail.co.uk --- Comment #1 from Lewis Cawte lewisca...@hotmail.co.uk 2010-07-22 17:55:00 BST --- Hm, the bolding is kinda weird, I've located the area thats causing it, just do we want to implement a fix (removing strong tags from (and around) line 54 of http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/CentralAuth/CentralAuthHooks.php) -- 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
[Bug 24498] SimpleSearch: Regression: Cannot drop text in the search box
https://bugzilla.wikimedia.org/show_bug.cgi?id=24498 --- Comment #7 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 17:04:53 UTC --- (In reply to comment #5) If only all browsers supported HTML5 yet, then this would be so much easier :D http://dev.w3.org/html5/spec/Overview.html#the-placeholder-attribute We use this if available, which is probably why this bug doesn't occur on Chrome. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #43 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-07-22
17:24:10 UTC ---
(In reply to comment #41)
The lack of the dfn element is a particular thorn in my side on Wikipedia
right
now, in reality and not in theory, as WP and other MW-based wikis
*overwhelmingly abuse* the dl/dt/dd elements all over the place (e.g. every
talk page!) for purely visual indentation (:) and/or boldfacing (;). A new
Bugzilla ticket (if one doesn't exist for this yet) needs to be opened to fix
this - replace all dl/dt/dd output of : and ; wikimarkup with CSS-styled
divs. The only way to distinguish a real definition (e.g. in a glossary,
in-article or as a stand-alone list article) at the Web semantics level (see
below for numerous reasons this is useful and important) from misuse of these
elements, is with the dfn element. See draft guideline at [[WP:GLOSSARY]],
and
its geeky-as-heck subpage for some detail on MW/WP evilbadness when it comes
to
definition and more general lists. For more background on the dfn element and
its stable HTML 5 future, see the
http://www.w3.org/TR/html5/text-level-semantics.html#the-dfn-element page.
That said (i.e. my personal reason for stumping for dfn), the dfn element is
also very useful all over Wikipedia and similar sites just by the element's
very nature. It should be one of the most-used. For example, I think that on
Wikipedia in particular, the bold-faced beginning of lead sections in
mainspace
articles should mostly be done with a template that auto-adds dfn, instead of
manual boldfacing, e.g.: An {{leadterm|electrokardiogram}} is... I mean,
really, that's precisely what this element exists for: To flag the defining
instance (in its context) of a term. The average human reader looking (i.e.
with working eyes in a typical browser) at a WP article might not experience
anything differently, but it has a lot of automated processing potential, and
accessibility improvement potential, especially in articles that present
several closely-related things in one article (e.g. submodels or trim levels
of a car, e.g. the GT Cruiser and Street Cruiser variants of the PT Cruiser).
With dfn support, users of text-to-speech screen readers would be able to
customize their style sheets to do something specific for dfn-flagged
defining
instances to help distinguish them from just another section and just
another boldfaced something.
I don't recall making any search-engine-related argument about dfn, though
there may well be one. And an argument like we shouldn't implement it
because
search engines don't use it (which I'm not sure was being made here, but it
kind of looked like it) is logically invalid anyway, since there may be many
other things/people that do/will use the feature under discussion for various
reasons and purposes (not to mention that it's tautological and circular - a
search engine can't use a wiki feature that isn't implemented, by definition,
ero the lack of evidence of the search engine using the feature on wikis
cannot
be used as an argument against the feature's wiki implementation, obviously -
it puts the cart before the horse).
So what you're saying is that theoretically someone somewhere might be able to
derive some benefit from this, but you don't have specific examples of people
who *will* benefit from it? Like who have said they want it and will use it
for some specific constructive purpose if it's available?
Maybe we should allow it even if it's only useful in theory, but if there were
real-world uses (i.e., non-hypothetical) then I'd certainly be fine with adding
it. I'd like to be clear one way or the other on that. (In contrast, I think
address certainly should not be added under any circumstances, and have
*very* strong doubts about kbd and samp given their incredibly limited
utility.)
Putting the address element back in since I and whoever first proposed adding
support for it, probably among others above, obviously do support adding it.
The address element isn't deprecated in HTML 5
(http://www.w3.org/TR/html5/sections.html#the-address-element), so DO include
it. It serves a well-defined semantic purpose just like every other
non-presentational element. It IS actually particularly useful on wikis (not
necessarily WikiPEDIA, mind you, but keep in mind that MW software can be used
for an endless number of end purposes, including databases of contact
information, etc.) when integrating metadata inline in the content with id=
and
a standardized metadata schema like hCard/vCard. It should be in the MW
software, and it should be up to individual installations' system operators
whether to turn that element off.
The address element gives contact information for the author of the page.
Since wiki pages are, by their nature, not owned by anyone or authored by any
single person, it makes no sense for wikis. If someone really
[Bug 24496] UniversalEditButton
https://bugzilla.wikimedia.org/show_bug.cgi?id=24496 Chad H. innocentkil...@gmail.com changed: What|Removed |Added CC||innocentkil...@gmail.com --- Comment #1 from Chad H. innocentkil...@gmail.com 2010-07-22 17:28:58 UTC --- Maybe in 1.18. Not trying to add any more features to the new installer for 1.17. -- 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
[Bug 24374] Create new usergroups at commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=24374 Cary Bass cb...@wikimedia.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #12 from Cary Bass cb...@wikimedia.org 2010-07-22 17:37:10 UTC --- In retrospect, I'm going to suggest that this userright be granted by local bureaucrats on request by OTRS admins (especially given that no small number of the Commons bureaucrats are stewards anyway). The Commons bureaucrats can certainly put a section on bureaucrat requests and easily follow through with granting access. Can we agree that it's okay for local bureaucrats to grant this? Cary -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #183 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-07-22 17:57:42 UTC --- Okay, look, if you make posts this long I'm not going to be able to read them. You have to state your points briefly and clearly, or else I'm just not going to have time to read through carefully and figure out exactly what you're trying to say. Walls of text are really not helpful. Furthermore, you're focusing too narrowly on implementation details, like the exact interface a function should implement. Please try to state your concerns primarily in terms of use-cases or problems -- scenarios that the implementation will need to handle. Secondarily, it's fine if you propose specific solutions, but I can't evaluate your solutions unless you state clearly what problems they're trying to solve. I'll comment on a few things you said. If I miss anything important, please restate it *briefly*, and I can address that too. (In reply to comment #172) What I wanted to say is that the computed sortkeys will have to be stored. But several sort keys for the same page in the same category are possible (one for each collation locale indicated by the target category). If we store separate sortkeys per category link per locale, it would take vastly too much space, since there are likely to be dozens of locales. categorylinks is already a big table; we can't justify making it ten times bigger for this. Each category can have one locale and only one locale. That sortkey is needlessly using the pageID within the generated sortkey (this is is visible when crossing a page limit and navigating throught pages) so in fact the unique index is on (categoryID, augmented sortkey). Conceptually wrong and bogous (I think this was just a fast patch when there were unicity problems and multiple pages could be specified with the same sortkey). It is not needless. We need a unique key to sort by, or else paging doesn't work if many pages have the same sort key (e.g., if it was manually assigned). See bug 4912. The generation of the concent of the sortkey column is the only major problem requiring a design decision. This is where it should not even depend on the SQL engine, and where it can be implemented within PHP, using the PHP extension that allows using ICU functions. That string does not have to be extremely long and does not have to be be humane readable. Yes, we will certainly use ICU or something. GerardM has said he much prefers CLDR, so maybe we'll use that instead. It can be safely be stored with a reasonnable length limit. So ICU-generated sortkeys are still safe if they get truncated. Notably because the unique index on: (categoryID, sortkey, pageID, localeID) is also unique on its restriction: (categoryID, pageID, localeID) And the sortkey generated by ICU, even if it's a string of binary bytes can still safely be stored in a table index that does not support blobs but want only VARCHAR(n) types, by serializing the binary sortkey to a safe encoding (the most basic that will work is hexadecimal) that does not even require the support of Unicode or UCA collation. Just use an ASCII only column to store the computed binary sortkey serialized as an ASCII-only string. But if the database engine supports strings of bytes, just don't serialize the blob, use the supported SQL type that can store it directly, for example VARBINARY(n), if it remains sortable in binary order. With this design, you are completely independant of the SQL engine, it will work identically on MySQL, PostrgresSQL, or others. And you'll have solved the problems of collation with multiple locales according to their rules, and possibly according to visitors preferences. This was always the intended design. (But note that truncating these sort keys might not always be fully safe: it could cause tons of collisions, depending on the nature of the sort key generation algorithm. These would be resolved arbitrarily, by page_id, which is confusing to users.) It's not a complicate design, and it offers stability warranties and supports as well the possibility of upgrading the collations. Upgrading the collation can be done in-place. The worst case is that categories sort weirdly for a few hours. Also, we would only realistically have to change the collation often on smaller wikis, since the largest wikis should have high-quality collations that cover almost all their pages to begin with. I don't think we need to adjust the schema to prepare for this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 23932] Enable, whitelist, and incorporate semantic HTML5 elements: article, aside, dialog, figure, footer, header, hgroup, mark, nav, section, time
https://bugzilla.wikimedia.org/show_bug.cgi?id=23932 --- Comment #6 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-07-22 18:08:35 UTC --- Sure, if someone can be bothered to add it as on off-by-default site option. Same for other similar things, like inline SVG. It can't be on by default, that's all. I'd still leave this RESOLVED LATER for now, though, because I don't trust that all of these elements are fully stable. -- 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
[Bug 24499] New: bugs.wikimedia.org no longer redirects
https://bugzilla.wikimedia.org/show_bug.cgi?id=24499 Summary: bugs.wikimedia.org no longer redirects Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: b...@mzmcbride.com bugs.wikimedia.org used to redirect to Bugzilla. It no longer does. It's referenced in the mailing list archives and elsewhere on the web, so it should probably be fixed. -- 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
[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671 --- Comment #44 from Michael Zajac mich...@zajac.ca 2010-07-22 13:38:19 CDT --- The address element gives contact information for the author of the page. Since wiki pages are, by their nature, not owned by anyone or authored by any single person, it makes no sense for wikis. Off the top of my head, an address element could be appropriate in the following places: * In the page footer, for the Wikimedia button. * On a user page or user talk page, where a wiki user provides contact information about themself. * In any content page or section, or documentation page or section, or Wikiproject page or section where some user is acting as maintainer or steward for some info. I have seen hundreds of various examples in Wikipedia and Wiktionary. (E.g., Wikipedia's [[Template:Maintained]].) In the context of a wiki, a link to a user page or user talk page is appropriate content for the address element. It makes no sense in normal wiki pages, though, and should not be allowed by default. What's a “normal” wiki page? This is general-purpose software. Allowing just what we need for Wikipedia will make all wikis look like Wikipedia. For goodness' sake, we have a million-definition multilingual dictionary with no dfn elements! Whitelisting HTML tags gives editors the opportunity to demonstrate demand by using them. Insisting that we don't whitelist tags because it is “anti-Wiki” is self-fulfilling. The whole point of Wikitext is to provide easy shortcuts, *without* artificially limiting editors. Yeah, it would be good to list more use cases. But this “we don't have it so it's not useful” argument is circular and by its nature unconvincing. Wikitext may be the world's most common way to generate HTML, and what we choose to allow in the software strongly affects what people will use, and not vice-versa. -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #184 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 18:40:19 UTC --- (In reply to comment #183) It is not needless. We need a unique key to sort by, or else paging doesn't work if many pages have the same sort key (e.g., if it was manually assigned). See bug 4912. It is needless in the sense that the cl_from field is right there and is indexed. We should just be using that field rather than tacking its contents onto the sortkey because we're too lazy to rewrite IndexPager so it can handle paging by more than one field (which is not very hard). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24496] UniversalEditButton
https://bugzilla.wikimedia.org/show_bug.cgi?id=24496 MarkDilley markwdil...@gmail.com changed: What|Removed |Added CC||markwdil...@gmail.com --- Comment #2 from MarkDilley markwdil...@gmail.com 2010-07-22 18:44:26 UTC --- My impression, which could be wrong, is that this was a standard on all Medawiki - so set to true would be the default. Hope that is what is settled on :-) -- 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
[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #185 from Aryeh Gregor simetrical+wikib...@gmail.com 2010-07-22 18:47:23 UTC --- Oh, I didn't get what he was saying. Yes, obviously we should use the actual cl_from field, not tack it onto cl_sortkey (is that what we do these days?). I'm going to have to make a lot of changes to the category pager anyway to support paging by multiple things, so I can do that while I'm at it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 457] Clean up use of header tags in MonoBook Vector skin UI elements
https://bugzilla.wikimedia.org/show_bug.cgi?id=457 Danny B. dann...@email.cz changed: What|Removed |Added Summary|Clean up use of header tags |Clean up use of header tags |in MonoBook skin UI |in MonoBook Vector skin |elements|UI elements -- 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
[Bug 24469] IE 6 still very slow
https://bugzilla.wikimedia.org/show_bug.cgi?id=24469 --- Comment #2 from Biezl m...@gmx.org 2010-07-22 19:26:56 UTC --- It's not a general problem, it's special for IE6, which is very slow in running JavaScript. Now FireFox is about as fast on Vector as MonoBook on my system. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24191] Signature button in Hungarian should produce – ~~~~
https://bugzilla.wikimedia.org/show_bug.cgi?id=24191
Tisza Gergő gti...@gmail.com changed:
What|Removed |Added
CC||gti...@gmail.com
--- Comment #4 from Tisza Gergő gti...@gmail.com 2010-07-22 19:33:06 UTC ---
Until this gets fixed, a Common.js-based workaround for interested parties:
if ( typeof $j != 'undefined' window.wgWikiEditorEnabledModules
wgWikiEditorEnabledModules.toolbar ) {
addOnloadHook( function() {
$j( '#wpTextbox1' ).bind( 'wikiEditor-toolbar-buildSection-main', function(
event, section ) {
section.groups.insert.tools.signature.action.options.post = '– ~~' +
'~~';
});
});
}
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
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
[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671
--- Comment #45 from Christopher Yeleighton giecr...@stegny.2a.pl 2010-07-22
19:33:30 UTC ---
(In reply to comment #37)
abbr instead. kbd and samp are basically useless. q is dodgy because
No, they are useful, albeit a limited domain. If HTML had been designed by
biologists, it would have SPECIES and FAMILY instead.
(In reply to comment #40)
If a wiki actually wants to use q despite the IE problems, it can request
that and it might be considered. I haven't seen such a request. If it were
Try HTML q element [1].
(In reply to comment #41)
That said (i.e. my personal reason for stumping for dfn), the dfn element is
also very useful all over Wikipedia and similar sites just by the element's
very nature. It should be one of the most-used. For example, I think that on
Wikipedia in particular, the bold-faced beginning of lead sections in
mainspace
articles should mostly be done with a template that auto-adds dfn, instead of
manual boldfacing, e.g.: An {{leadterm|electrokardiogram}} is... I mean,
really, that's precisely what this element exists for: To flag the defining
instance (in its context) of a term.
I would rather say [[{subst:PAGENAME}]] and leave inserting the DFN tags to the
engine. (I admit I have changed my position on this subject.)
major browsers treat it the same. Normally I will never bend at all to suit
broken Microsoft apps, but this issue actually goes beyond that, as some
browsers do not auto-insert quotation marks,
HTML5 goes flip-flop about this. The version I have in memory cache says
quotation marks should be explicit inside Q.
I am trying to figure out the best way to replace the tt element as I
migrate to HTML5.
The wiki way of embedding code sections is to put white space on the beginning
of the line. This leaves the question of in-line code; software manuals need
this but it is a very special application. I cannot imagine an example of
in-line output.
(In reply to comment #43)
I'd like to see specific examples of screen readers or power-users'
stylesheets
that do not treat these the same as code or tt, since you say these are
near certain or absolutely certain.
My Internet Explorer used to render CODE in 10pt and SAMP in 12pt, probably
upon assumption that CODE is for nerds with big lenses ;-)
___
[1]
URL:http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Archive_103#HTML_q_element
--
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
[Bug 209] XHTML compliance (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=209 Danny B. dann...@email.cz changed: What|Removed |Added Depends on||24500 -- 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
[Bug 367] Markup accessibility issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=367 Danny B. dann...@email.cz changed: What|Removed |Added Depends on||24500 -- 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
[Bug 24500] New: Do not output empty portlets
https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 Summary: Do not output empty portlets Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: accessibility Severity: minor Priority: Normal Component: Vector Skin AssignedTo: tpars...@wikimedia.org ReportedBy: dann...@email.cz Blocks: 209,367 Do not output empty portlets. 1) It is not valid. ul/ul is invalid. 2) They are not shown, but they are present in HTML, so: a) useless cluttering of output code b) unnecesssary increase of DOM structure c) accessibility issues -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24180] Undefined behavior for #arraymap on empty separator
https://bugzilla.wikimedia.org/show_bug.cgi?id=24180 Derk-Jan Hartman hart...@videolan.org changed: What|Removed |Added CC||hart...@videolan.org Summary|Undefined behavior for |Undefined behavior for |#arramap on empty separator |#arraymap on empty ||separator -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24500] Do not output empty portlets
https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 MZMcBride b...@mzmcbride.com changed: What|Removed |Added CC||b...@mzmcbride.com --- Comment #1 from MZMcBride b...@mzmcbride.com 2010-07-22 19:45:41 UTC --- Fairly sure this was addressed in bug 23015 and bug 23575. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24500] Do not output empty portlets
https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||roan.katt...@gmail.com Resolution||DUPLICATE --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 20:01:18 UTC --- (In reply to comment #1) Fairly sure this was addressed in bug 23015 and bug 23575. Yes, this is a duplicate. Also, there's, what, one or two potentially empty uls on the entire page? *** This bug has been marked as a duplicate of bug 23015 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 23015] Make vector skin standards compliant (CSS/HTML)
https://bugzilla.wikimedia.org/show_bug.cgi?id=23015 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||dann...@email.cz --- Comment #10 from Roan Kattouw roan.katt...@gmail.com 2010-07-22 20:01:18 UTC --- *** Bug 24500 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 367] Markup accessibility issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=367 Bug 367 depends on bug 24500, which changed state. Bug 24500 Summary: Do not output empty portlets https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE -- 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
[Bug 209] XHTML compliance (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=209 Bug 209 depends on bug 24500, which changed state. Bug 24500 Summary: Do not output empty portlets https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE -- 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
[Bug 24488] Don't encourage users to insert deprecated presentational tags by presence of such buttons on edit toolbar
https://bugzilla.wikimedia.org/show_bug.cgi?id=24488 --- Comment #4 from parul pv...@wikimedia.org 2010-07-22 20:08:07 UTC --- if i remember correctly, these buttons were used in our old (and new?) tool bar click tracking in japanese. with our other font size issues in script language, i wouldn't be surprised if this was the case for chinese, korean, etc... we were actually going to take these out a while back until we saw that data and decided to keep it in until another point of view (read: pleas to remove them) surfaced. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24491] Users shouldn't be given Upload a new version of this file when a file is protected
https://bugzilla.wikimedia.org/show_bug.cgi?id=24491 --- Comment #2 from Guillaume Paumier gpaum...@wikimedia.org 2010-07-22 20:14:50 UTC --- Derk-Jan is right, hiding it completely from the description page of a protected image would probably be confusing. I do understand Liangent's rationale though. A simple fix could be to replace the link for protected images by a message saying the file is protected, and linking to the upload page *without* prefilling the destination name (that way, the file won't be replaced). It would add clutter to the page, but we have plans to revamp it in the medium term anyway. -- 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
[Bug 24485] Make iwbacklinks a generator, display iwprefix and iwtitle optionally
https://bugzilla.wikimedia.org/show_bug.cgi?id=24485 --- Comment #1 from Reedy s...@reedyboy.net 2010-07-22 20:23:03 UTC --- Optional parameters in r69749 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 671] Whitelist non-problematic HTML tags: dfn samp kbd address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671 --- Comment #46 from Christopher Yeleighton giecr...@stegny.2a.pl 2010-07-22 20:48:22 UTC --- (In reply to comment #44) Off the top of my head, an address element could be appropriate in the following places: * In the page footer, for the Wikimedia button. This case does not need white-listing. -- 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
[Bug 24501] New: [SMWWriter] [Needs review] Check that value is not empty before doing getHash()
https://bugzilla.wikimedia.org/show_bug.cgi?id=24501 Summary: [SMWWriter] [Needs review] Check that value is not empty before doing getHash() Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: ASSIGNED Keywords: need-review, patch Severity: critical Priority: Normal Component: [other] AssignedTo: denny.vrande...@kit.edu ReportedBy: samuel.la...@gmail.com CC: samuel.la...@gmail.com Error messages of the type Fatal error: Call to a member function getHash() on a non-object in [...]SMWWriter on line 82 It was solved by adding a check that it is not empty, before doing getHash, in function removePropertynameValue() (see attached patch). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24501] [SMWWriter] Check that value is not empty before doing getHash()
https://bugzilla.wikimedia.org/show_bug.cgi?id=24501 Samuel Lampa samuel.la...@gmail.com changed: What|Removed |Added Summary|[SMWWriter] [Needs review] |[SMWWriter] Check that |Check that value is not |value is not empty before |empty before doing |doing getHash() |getHash() | --- Comment #1 from Samuel Lampa samuel.la...@gmail.com 2010-07-22 20:59:17 UTC --- (Removed unnecessary tag in title) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24502] New: Multiple interwikis to same Wikipedia not displayed in API
https://bugzilla.wikimedia.org/show_bug.cgi?id=24502 Summary: Multiple interwikis to same Wikipedia not displayed in API Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: API AssignedTo: roan.katt...@gmail.com ReportedBy: smole...@eunet.rs CC: bryan.tongm...@gmail.com, s...@reedyboy.net, vasi...@gmail.com, soxre...@gmail.com If an article has multiple interwiki links to the same language, they are properly displayed in the list of languages, but only one of them is displayed in the API. Steps to reproduce: 1) Go to http://en.wikipedia.org/wiki/Open_source . If no one changed the article, there should be two interwiki links to Sorani Wikipedia (language code csb): سەرچاوە کراوە and ژێدەرکراوە. 2) Go to http://en.wikipedia.org/w/api.php?action=queryprop=langlinkslllimit=500titles=Open_source . There is only one link to ژێدەرکراوە, the other link is not in the list. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
[Bug 24485] Make iwbacklinks a generator, display iwprefix and iwtitle optional
https://bugzilla.wikimedia.org/show_bug.cgi?id=24485 Reedy s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|Make iwbacklinks a |Make iwbacklinks a |generator, display iwprefix |generator, display iwprefix |and iwtitle optionally |and iwtitle optional --- Comment #2 from Reedy s...@reedyboy.net 2010-07-22 21:03:52 UTC --- r69753 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- 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
