[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164 --- Comment #131 from Andrew Dunbar hippytr...@gmail.com 2009-11-19 08:11:38 UTC --- Well, there are people who know the architecture and the programming language and can presumably do this very quickly (at least the basic step) Why do you presume it can be done quickly? It doesn't seem so to me and I regard this bug to be of huge importance. if they realize how much of a priority it is. The first step is just to apply a few extra functions to category sort keys with the intention of converting them into collation keys. Which functions would those be? What makes you think category sort keys can be converted to collation keys? For instance category sort keys are human-readable and human editable but collation keys are typically binary and not human readable. Category sort keys are included directly in the text of a category link such as [[Category:foo|bar]]. Do to their binary nature collation keys cannot appear here. So you would need to decide whether to remove all category sort keys or make category sort keys interact with collation keys that would be added elsewhere. For collation keys to replace category sort keys you would need to establish that cateogry sort keys have no legitimate uses other than forcing alphabetic order in cases where the current order results in nonalphabetic sequences. I can assure you that people do use category sort keys for other purposes and some might be vociferously upset if these were removed without discussion. For collation keys to interact with category sort keys you need to generate and maintain in the database, collation keys for each page title and for each category sort key since collation keys must be of the same nature to be able to compare and hence sort them. Now Unicode does specifiy a Unicode Collation Algorithm (UCA) which we could and probably should use. It is language agnostic but provides for tailoring for individual languages. The UCA definitely generates binary keys. Not printable. Not human readable. UCA keys can be very long. I use them in an offline tool for the English Wiktionary and initially set their maximum length to 1024, 4 times the maximum length of a page title. We already had about 10 pages for which 1024 was too short so I had to set it to 2048! Many people might not like all page titles and category sort keys to now require 9x their current amount of space in the database. UCA does allow for various types of sort key compression however. In which case we would need to choose one to use since it will not be possible to mix and match them. PHP currently seems to have no implementation of UCA. We would need to create it from scratch, or find a way to use one in C. For multilingual wikis such as Commons and all of the Wiktionaries just havine one collation language will not work since users of each language will expect things to be in the correct order for their language. For the Wiktionaries this means each category needs a way to declare which language collation to use and each page needs to declare which subset of possible language collation keys to generate for that page. For Commons I'm not sure what the requirements would be but the may differ from those of the Wiktionaries. These new fields will need support in the database schema. The ones requiring multiple language collations will reqire more drastic database changes quite different from what we now have. Once that's in place, people can work on actually writing such functions for their particular languages. Later, when those functions are written, they can be used additionally to generate a proper alphabetically ordered table of pages for use in the contents listings. Or some similar workflow UCA tailoring would make the particular language collations very easy as long as we have a decent implementation of UCA that easily works with tailoring. - but there needs to be a plan of action, and that can't be effected by just anyone, only by the devs who are in charge (no use pretending that everyone's equal - only certain devs actually have the power to make anything happen). Not true. Anyone with commit access can add such code. Myself for instance. My understaning is that there are not technically any dev in charge at the moment since Brion stepped down though there certainly are a few such as Tim who are acknowledged to have a greater understanding of the entire codebase and hence greater trust, and you definitely want those people to check such changes and would expect them to revert any premature commits. -- 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 #132 from Philip Tzou philip@gmail.com 2009-11-19 08:27:39 UTC --- I'm busy with my study and I can't help this until I have passed my exam next year January. I'm sorry to make your guys unhappy, though Chinese Wikipedia also needs such functions. :) -- 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 21566] Request for enabling Collection Extension for Vietnamese Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=21566 Leinad danny.lei...@gmail.com changed: What|Removed |Added CC||danny.lei...@gmail.com Keywords||shell -- 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 4397] Time based anti-vandalism feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=4397 Thomas Bertels tbertels+bugzi...@gmail.com changed: What|Removed |Added CC||tbertels+bugzi...@gmail.com --- Comment #22 from Thomas Bertels tbertels+bugzi...@gmail.com 2009-11-19 10:28:22 UTC --- (In reply to comment #21) However, it also seems from data from the German trial that no reduction in vandalism was observed from FlaggedRevs I'd be interested to read the full study, if you have the link handy. Or if you remember somewhat where you read it. -- 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 21567] New: Toolbar buttons (bold) insert text on top or somewhere
https://bugzilla.wikimedia.org/show_bug.cgi?id=21567 Summary: Toolbar buttons (bold) insert text on top or somewhere Product: MediaWiki extensions Version: any Platform: All URL: http://de.wikipedia.org OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: flax...@googlemail.com CC: wikibugs-l@lists.wikimedia.org, roan.katt...@gmail.com This occurs only when I scrolldown within the editfield and press bold. Using FF and IE on Windows7. -- 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 21567] Toolbar buttons (bold) insert text on top or somewhere
https://bugzilla.wikimedia.org/show_bug.cgi?id=21567 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2009-11-19 11:45:48 UTC --- *** This bug has been marked as a duplicate of bug 21492 *** -- 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 21492] Toolbar buttons insert text on top in IE
https://bugzilla.wikimedia.org/show_bug.cgi?id=21492 --- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2009-11-19 11:45:48 UTC --- *** Bug 21567 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 21492] Toolbar buttons insert text on top in IE
https://bugzilla.wikimedia.org/show_bug.cgi?id=21492 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Roan Kattouw roan.katt...@gmail.com 2009-11-19 11:46:21 UTC --- Reports that this is not fixed on dewiki, see bug 21567. Will investigate. -- 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 21563] Add Extension:QPoll to bugzilla
https://bugzilla.wikimedia.org/show_bug.cgi?id=21563 Dmitriy Sintsov ques...@rambler.ru changed: What|Removed |Added CC||ques...@rambler.ru Status|NEW |ASSIGNED --- Comment #2 from Dmitriy Sintsov ques...@rambler.ru 2009-11-19 12:06:33 UTC --- Ok, I may recieve the extension's bug reports by default. -- 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 21568] New: Missing hooks in SQLStore2
https://bugzilla.wikimedia.org/show_bug.cgi?id=21568 Summary: Missing hooks in SQLStore2 Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Keywords: need-review, patch Severity: enhancement Priority: Normal Component: Semantic MediaWiki AssignedTo: mar...@semantic-mediawiki.org ReportedBy: avino...@gmail.com CC: avino...@gmail.com Created an attachment (id=6804) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6804) Adding before and after hooks for updateData and deleteSubject. It's difficult to integrate into the SMW logic (for debugging, profiling and experimental modifications), because SQLStore2 doesn't fire any events. As an example, I need these hooks in order to determine (atomically, not via onSave hooks) what semantic data was changed in order to purge related api requests from varnish. This is just one example though. -- 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 #133 from Le Chat cat...@vp.pl 2009-11-19 12:53:22 UTC --- We seem to be overcomplicating things now. Of course category sort keys and binary collation keys are different beasts. We just need a couple of stub functions (we - or rather individual projects - can worry about what they should do later), F1 and F2, such that F1(T) means the collation key derived from page title T, and F2(K) means the collation key derived from human-readable category sort key K (the two functions will be similar, but potentially not identical). Then apply them at the appropriate places in the code generating the category listings. There will also need to be a function that retrieves the first letter back from a binary key, as has been noted. All these functions will be language- and project-dependent - no-one is in a position to write all of them, but once the basic (and trivial) framework is in place, people who know about the various languages will be able to work on writing these functions. If a project thinks it needs the option of multiple sort algorithms, then that's pretty simple to implement as well, though starting with just one algorithm per project seems perfectly satisfactory - all the main public-facing projects are language-specific anyway, so even if English Wiktionary contains Czech words, we would still expect them to be sorted in the English order. -- 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 21563] Add Extension:QPoll to bugzilla
https://bugzilla.wikimedia.org/show_bug.cgi?id=21563 Chad H. innocentkil...@gmail.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Chad H. innocentkil...@gmail.com 2009-11-19 13:11:51 UTC --- Alrighty, component added with QuestPC as default CC. -- 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 21554] Missing second-level replies in thread permalink view
https://bugzilla.wikimedia.org/show_bug.cgi?id=21554 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrew Garrett agarr...@wikimedia.org 2009-11-19 14:16:38 UTC --- Resolved. -- 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 21569] New: Error while trying to donate by CreditCard
https://bugzilla.wikimedia.org/show_bug.cgi?id=21569 Summary: Error while trying to donate by CreditCard Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: abi...@forgotten-beauty.com Hello, I recieved a lot of emails in the Fundraising queue on OTRS about the failure when they try to donate with a creditcard. The error: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function Database::insert. MySQL returned error 1062: Duplicate entry '0' for key 2 (db9.pmtpa.wmnet). Is it possible to get it fixed, because it sends the donation but doesn't give a message that the donation is done. Huib -- 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 21439] Activate autopatrol user group for Simple English Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=21439 --- Comment #2 from barras...@web.de 2009-11-19 15:00:13 UTC --- Would it be possible to get some attention on this? I think it isn't that much work, because the needed change of the code is mentioned above. It would be nice if someone could take care of this. Thanks [[m:User:Barras]] -- 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 19523] prop=infoinprop=watched
https://bugzilla.wikimedia.org/show_bug.cgi?id=19523 Reedy s...@reedyboy.net changed: What|Removed |Added AssignedTo|roan.katt...@gmail.com |s...@reedyboy.net -- 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 20924] binary files are incorrectly detected as application/zip
https://bugzilla.wikimedia.org/show_bug.cgi?id=20924 Carl Johnstone carl.johnst...@gmgrd.co.uk changed: What|Removed |Added CC||carl.johnst...@gmgrd.co.uk Summary|certain mac word (2000) .doc|binary files are incorrectly |files are incorrectly |detected as application/zip |detected as application/zip | --- Comment #3 from Carl Johnstone carl.johnst...@gmgrd.co.uk 2009-11-19 14:59:06 UTC --- I've had this with a Windows Word document, unfortunately it also happened to be the first file I tried to upload to a newly installed wiki. In theory there's approximately a 1 in 65000 chance that the check will match any 64k of binary data and would equally apply to any file type including images. Ideally the detection needs to be improved, failing that a clearer error message to the user would help. -- 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 21346] Make deleted images searchable by hash
https://bugzilla.wikimedia.org/show_bug.cgi?id=21346 Reedy s...@reedyboy.net changed: What|Removed |Added CC||s...@reedyboy.net --- Comment #1 from Reedy s...@reedyboy.net 2009-11-19 15:21:10 UTC --- Hmmm This looks like it might be fairly simple.. The functionality is there for normal images, its only a case of duplicating/reusing it on the filearchive table.. -- 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 #138 from Le Chat cat...@vp.pl 2009-11-19 15:27:02 UTC --- 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. Not if you compute the collation key when you add a page to a category, and index it based on that key. (Just as you currently index it based on the human-readable sort key.) -- 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 20812] Wikisource: IPs unable to flag articles as proofread
https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 John Mark Vandenberg jay...@gmail.com changed: What|Removed |Added CC||jay...@gmail.com --- Comment #28 from John Mark Vandenberg jay...@gmail.com 2009-11-19 15:31:21 UTC --- Please provide unified diffs using diff -ur old/ new/ More fundamentally, I think it is necessary for the Proofread Page extension to not include access control. It should probably use the userCan hook, and let another extension implement access control. http://www.mediawiki.org/wiki/Manual:Hooks/userCan I would prefer to see a matrix that defines what user groups are able to perform tasks at various stages. The following would prevent IPs from proofreading pages. $wgGroupPermissions['autoconfirmed']['proofread'] = true; $wgProofreadPageStageProtection['*'] = array( 'proofread' ); The following would prevent IPs from validating pages. $wgGroupPermissions['autoconfirmed']['validate'] = true; $wgProofreadPageStageProtection[3] = array( 'validate' ); It should be possible to add a sysop-only fourth stage with: $wgGroupPermissions['sysop']['finalise'] = true; $wgProofreadPageStageProtection[4] = array( 'finalise' ); Another approach would be: $wgProofreadPageMaxStage['anon'] = 1; $wgProofreadPageMaxStage['autoconfirmed'] = 3; $wgProofreadPageMaxStage['sysop'] = 4; -- 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 #139 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 15:51:05 UTC --- #88,#100,#101 Does UCA explicitly specify the binary representation of the generated key? yes and no: - Yes there's an interface to retrieve the computed sort key. - But no: it is not stable across versions of Unicode (which can add characters in the DUCET), of ICU (that can change the representation), and of CLDR (that can modify also the locale-dependant tailorings). In other words : precomputed (stored) collations will need to be versioned too, any upgrade will require recomputing the collation keys (but a real problem on large wikis, if this is implemented in the SQL native engine (because the database index will have to be FULLY rescanned and updated, which may take a considerable down time on large wikis). This will be much less problematic if the colaltion keys are not part of the SQL engine itself, but stored in a separate table that can store multiple keys for distinct collations, because it can also be used for storing successive versions. In that case, recomputing the collation keys can be deferred, and once a category is finished, the collation version can be updated in the category, and then the collation keys for the previous version can be deleted, and then the next category can be handled. This will imply NO downtime on the server, as new collations can be added on the fly (and separately for each category). Consequence: add to the MediaWiki data model a table of supported locales-collation (those that can be specified in the site-wide default) with their supported version. Attach a unique id for the versioned collation, and create a separate category collation table containing the collation keys. Conceptually (some details omitted) : CREATE TABLE collations( coll_id INTEGER NOT NULL, -- primary key for this table coll_name VARCHAR(32) NOT NULL,-- e.g. root, fr, en-US, en-GB, zh-Latn, zh-Bopo, zh-Hans.radical-strokes coll_isprefered SMALLINT NOT NULL, -- identifier of the version coll_version VARCHAR(32) NOT NULL, -- unique description of the version PRIMARY KEY (coll_id), UNIQUE KEY(coll_name, coll_version), -- strong constraint INDEX ON (coll_name, coll_ispreferred) -- optional, for fast retrieval of the prefered version of a given collation ); CREATE TABLE categorysort ( cl_id INTEGER NOT NULL, -- in fact, the primary key of the categorylinks table coll_id INTEGER NOT NULL, -- primary key of the collations table cs_key VARCHAR(255), -- in fact a binary value, computed from ICU's Collator:getKey(UString). PRIMARY KEY(cl_id, coll_id) ); Then no need to change the categorylinks table, which will continue to store the full pagename, and the custom sortkey. To support the firstChar() conceptual API, each entry in the collations table above would also need another table containing the possible lowest strings (in collation order) that use the same weight value at the primary level: CREATE TABLE collations_headings( coll_id INTEGER NOT NULL, -- primary key of the collations table ch_weight INTEGER NOT NULL, -- primary collation weight value ch_cluster VARCHAR(32) NOT NULL -- single default grapheme cluster from the first string starting with this primary weight. PRIMARY KEY (coll_id, cf_cluster) ) One problem is that ICU does not currently contains such a list of default grapheme clusters suitable for all primary weight values in each collation. Is there a way to generate it anyway? Note that some primary weights can sometimes only exist with multiple characters E.g. ch is a default grapheme cluster in the Breton collation, LC_COLLATE=br. It makes no sense in Breton to mix c and ch together under the same heading, given that they sort separately. The same thing occurs in many languages (e.g. Spanish, Swedish...). However it probably does not occur (?) in the DUCET (I did not verify this assertion), so may be we can just avoid storing all possible Unicode characters to convert them to their default primary heading, and instead we just have to store the graphemes specified in the examplar set for the language (or other graphemes that are explicitly present in the locale specific tailoring rules. The other graphemes usable as first char can then be taken automatically generated from the first Unicode character present in the Mediawiki custom cl_sortkey (whose default is the full pagename, including the namespace name localized to the default locale of the wiki), according to the DUCET which is shared as the base of all locales. -- 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 #140 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 15:59:48 UTC --- #138: I fully agree. Using stored collation keys will remove the dependency with the database support, and will also avoid the problem of downtime when upgrading the collations and recomputing the categorylinks SQL index to migrate the collation keys... I still defned the concept of multiple collations in parallel, if only just for supporting the migration of collation rules. In addition it will offer users preferences for their preferred collation order, and will also allow to view the same category using different orders, without additional processing (as long as the category page itself, or the site-wide default collations, specify the collations as supported by default) -- 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 #141 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 16:09:07 UTC --- #137 From Roan Kattouw 2009-11-19 14:17:38 UTC (In reply to comment #134) Tdoday, basically, the categories are sorted by [sort key, full page name]. (possibly truncated to a reasonable size using unique identifier). This is not true. We're sorting by (sort key, pageID) where the sortkey is whatever the page sets as sortkey (or the page name if not set), and pageID is a unique number identifying the page (roughly proportional to creation time). I was speaking conceptually. The pageID is absolutely not conceptual and makes absolutely no sense lingusitically for most users, for sorting pages having the same sort key specified. We really want these pages to be sorted according to the specified sort key (when it is present), then by the full page name; and both using the same locale-dependant collation order. The pageID was just added to make sure that the sort key was unique (actually this is not a requirement), and for allowing navigation from page to page without missing entries or duplicating them across pages, but it is definitely not part of a good sort key (this is the only reason why we want a unique id there, but in fact it is redundant and is an alternate binary representation of the full pagename which is also unique, but which is completely unsuitable for collation). -- 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 #142 from Roan Kattouw roan.katt...@gmail.com 2009-11-19 16:40:25 UTC --- (In reply to comment #141) The pageID was just added to make sure that the sort key was unique (actually this is not a requirement), It is a requirement software-wise. If two categorylinks entries are indistinguishable, category paging will break. and for allowing navigation from page to page without missing entries or duplicating them across pages, Exactly. but it is definitely not part of a good sort key (this is the only reason why we want a unique id there, but in fact it is redundant and is an alternate binary representation of the full pagename which is also unique, but which is completely unsuitable for collation). Yeah the full page name could also be used as a tiebreaker (from a technical standpoint we probably want a (namespace, title) pair instead, where namespace is a numeric value). -- 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 21462] Posting an reply to message at Special:NewMessages breaks the view
https://bugzilla.wikimedia.org/show_bug.cgi?id=21462 --- Comment #4 from Niklas Laxström niklas.laxst...@gmail.com 2009-11-19 17:12:33 UTC --- Didn't seem to occur when I last tried that. -- 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 21541] Pre-save transform not applied to LiquidThreads signatures
https://bugzilla.wikimedia.org/show_bug.cgi?id=21541 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 21462] Posting an reply to message at Special:NewMessages breaks the view
https://bugzilla.wikimedia.org/show_bug.cgi?id=21462 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andrew Garrett agarr...@wikimedia.org 2009-11-19 17:13:03 UTC --- Assuming FIXED. -- 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 21466] Exception: Post 50 has contaminated reply 50
https://bugzilla.wikimedia.org/show_bug.cgi?id=21466 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andrew Garrett agarr...@wikimedia.org 2009-11-19 17:29:04 UTC --- Unable to reproduce. -- 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 21570] New: dropdown tab border go over baseline
https://bugzilla.wikimedia.org/show_bug.cgi?id=21570 Summary: dropdown tab border go over baseline Product: MediaWiki extensions Version: any Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: Normal Component: UsabilityInitiative AssignedTo: tpars...@wikimedia.org ReportedBy: flax...@googlemail.com CC: wikibugs-l@lists.wikimedia.org using 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 17486] Parser generates invalid XHTML with a list inside a table
https://bugzilla.wikimedia.org/show_bug.cgi?id=17486
--- Comment #11 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 17:34:54
UTC ---
Well the above comments for improving the syntaxe lists, indented blocks and
section headings should probably be part of a request for enhancement (because
they have possible compatibility issues in some articles).
But the improvement for tables should still be part of this bug (as they don't
cause compatibility issues: pipes have no function in the current table first
line starting by {|.
Another alternative for single line tables would be to recognize them only if
they start with {|| without any space within the 3 characters, before its
attributes, in which case tables would be recognized even in the middle of a
wiki-line.
--
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 21553] Remove LiquidThreads customisation of recentchanges
https://bugzilla.wikimedia.org/show_bug.cgi?id=21553 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrew Garrett agarr...@wikimedia.org 2009-11-19 17:36:34 UTC --- Done. -- 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 21458] IE7 apparently unable to display edit box at nesting level 9
https://bugzilla.wikimedia.org/show_bug.cgi?id=21458 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrew Garrett agarr...@wikimedia.org 2009-11-19 17:38:42 UTC --- This has been resolved. -- 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 21570] dropdown tab border go over baseline
https://bugzilla.wikimedia.org/show_bug.cgi?id=21570 --- Comment #1 from Trevor Parscal tpars...@wikimedia.org 2009-11-19 17:46:19 UTC --- Can we get some more information on which version of the browser, a more complete description of the problem and possibly a screenshot? -- 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 235] Auto unit conversion
https://bugzilla.wikimedia.org/show_bug.cgi?id=235 Aryeh Gregor simetrical+wikib...@gmail.com changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m --- Comment #27 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-11-19 17:55:16 UTC --- Adding this to ParserFunctions might make sense. Changing based on user preference is unlikely, but who knows. Nobody appears to be interested from the developer side right now. -- 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 19523] prop=infoinprop=watched
https://bugzilla.wikimedia.org/show_bug.cgi?id=19523 Reedy s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Reedy s...@reedyboy.net 2009-11-19 17:58:45 UTC --- Fixed in r59258 -- 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 #143 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 17:58:47 UTC --- (in reply to comment #142 from Roan) The pageID was just added to make sure that the sort key was unique (actually this is not a requirement), It is a requirement software-wise. Absolutely not, it is not required FOR SORTING (this was explicitly stated in my previous statements, dont cut it where you think it arranges you). It does not have to be software-wise, because exactly it is completely undesirable for sorting. You are confusion uniqueness requirements (for navigation and indexing for fast SQL retrieval) with sort order requirements. The need for the separate id is completely orthogonal, because the ID is just a small alias strictly equivalent to the full page name that it represents (i.e. to the unique identifier created by the namespace and the page name, which are what we really want to show and sort, but not what we need to avoid duplicated or missed entries in the next 200/previous 200 links). Such page id should always remain invisible in the GUI interface (only visible in the URL as a query parameter for the next/previous 200 links), and should be COMPLETELY ignored by the SQL ORDER BY clause, even if it MUST still be part of the SELECT'ed columns in the SQL query. Couldn't the namespace be part of the [[category-sort-option:]] or similar ? Currently they are sorted by name (and the initial of the namespace name is also used to generate the headings : it is convenient for some categories, but not all, and in fact, the namespace could be used to generate other subheading levels, or given lower prirority when compared to the unprefixed pagename. I see no valid option for sorting by numeric namespace id (except for sorting by namespaces, independantly of their name), and at least it should never be made visible in the first char used in section heandings... So may be another [[category-ns-option:]] could be set in category pages (but this will probably be part of another proposal for enhancement). -- 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 #144 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 18:12:31 UTC --- Note that in SQL, the ORDER BY clause needs NOT unique sort keys. Not even for sort stability, because the SQL engine will ensure the sort stability itself from the default store order in the index (when there's a qualifying index for this sort order), or from the implicit positional rowID's automatically for each SELECT'ed row added to the temporarily created table/index during the query execution. Some SQL engines (like Oracle, Sybase, Informix, but probably not all index formats supported in various versions of MySQL) also store the rowID's of the component tables from which columns are extracted in the SELECT clause, in order to allow the columns under the read cursor to be updatable, but won't do that for columns computed from expressions, which are not updatable. This just requires opening the cursor FOR UPDATE (and sometimes, you can also limit the list of table columns that need to be updated within the cursor loop, which remains open during the transaction, in order to minimize the extra storage for dependant rowID's). -- 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 21457] Spammed by thread traffic
https://bugzilla.wikimedia.org/show_bug.cgi?id=21457 Philippe Verdy verd...@wanadoo.fr changed: What|Removed |Added CC|verd...@wanadoo.fr | --- Comment #17 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 18:34:59 UTC --- #14: if you're so email sensitive, you can disable being sent emails... This is what was configured in all wikis. Until LiquidThread was added that forced the subscription without asking me. Yes I have removed the FORCED subscriptions from the wikis that have sent me tons of emails through LQT. I just hope that this won't occur in other wikis that I have visited in the past for some very active pages, when they will adopt LQT with the default on subscription option, despite ALL other email options were already disabled there (including for messages sent on my talk page on almost all wikis, except only ONE that I regularly visit, because my user page explicitly says where to post comments and how to contact me). For me it's much enough that all people can contact me via the talk page of my main wiki that I have publicized (and the admins of the wikis can still write to my email address in case of emergency): the talk page on my main wiki is still a perfect contact address for almost all people, and a valid substitute to an email address that I don't want to be polluted by messages coming from possibly hundreds of sources, and I better trust the admins on my main wiki than the few non-working admins of small wikis which are regularly spammed without much active control. -- 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 21358] Filter reacted but it shouldn't
https://bugzilla.wikimedia.org/show_bug.cgi?id=21358 Lolsimon lolsi...@wikipedia.be changed: What|Removed |Added Severity|enhancement |major -- 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 21569] Error while trying to donate by CreditCard
https://bugzilla.wikimedia.org/show_bug.cgi?id=21569 Tomasz Finc tf...@wikimedia.org changed: What|Removed |Added CC||tf...@wikimedia.org Status|NEW |ASSIGNED --- Comment #1 from Tomasz Finc tf...@wikimedia.org 2009-11-19 18:45:50 UTC --- I backed out two live changes to mitigate this. One that was passing an errant contribution id and another that was incrementing a unique id. Either of these could have caused for a duplicate unique key entry. -- 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 21358] Filter reacted but it shouldn't
https://bugzilla.wikimedia.org/show_bug.cgi?id=21358 --- Comment #7 from Andrew Garrett agarr...@wikimedia.org 2009-11-19 18:47:06 UTC --- I can see that the hit should not have occurred, but I have no way of testing or reproducing it, unless somebody can show me a consistent way of reproducing the 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 16884] Feed links in sidebar should comply to the parameters of displayed page
https://bugzilla.wikimedia.org/show_bug.cgi?id=16884 Matěj Grabovský mgrabov...@yahoo.com changed: What|Removed |Added CC||mgrabov...@yahoo.com Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Matěj Grabovský mgrabov...@yahoo.com 2009-11-19 19:00:32 UTC --- Fixed in r59262. -- 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 3646] RSS, Atom, XML syndication feeds (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=3646 Bug 3646 depends on bug 16884, which changed state. Bug 16884 Summary: Feed links in sidebar should comply to the parameters of displayed page https://bugzilla.wikimedia.org/show_bug.cgi?id=16884 What|Old Value |New Value Status|NEW |RESOLVED Resolution||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 3615] blocks of code not handling magic character conversions in Esperanto correcty (as reason for page deletion etc.)
https://bugzilla.wikimedia.org/show_bug.cgi?id=3615 Philippe Verdy verd...@wanadoo.fr changed: What|Removed |Added CC||verd...@wanadoo.fr Priority|Low |Normal --- Comment #13 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 19:02:42 UTC --- I still think that the esperanto specific magical conversion is a hack that should not be present in the MediaWiki stoftware itself, but that should only be offered as an edit tool that will manually convert selected characters to actual esperanto. This should then be supported only within a gadget for the page editor, or a more general gadget for use in various forms (like the Search form). The conversion should be explicitly requested, otherwise nothing should be done automagically as this breaks too often. This also means that the esperanto messages (in the MadiaWiki: namespace) need to be created on TranslateWiki with the correct characters (you may ask to TranslateWiki to add a gadget for esperantists that can't type the circumflexes on their keyboard, but I really suggest that the esperanto wiki documents how to create or install a keyboard layout to support the circumflex diacritic directly (because this is really easy in Windows and Linux; I don't know if this is possible as easily on MacOSX, but I suppose that tools similar to MSKLC for Windows also exist on MacOSX). If there remains incorrect links using extra x characters or where characters where converted to esperanto that should not have been converted on EO:WP, this has to be fixed within the articles. But the magic conversion after pressing the Publish button is really a bad thing with unsolvable problems. -- 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 235] Auto unit conversion
https://bugzilla.wikimedia.org/show_bug.cgi?id=235
--- Comment #28 from Sylvain Leroux sylv...@chicoree.fr 2009-11-19 19:05:04
UTC ---
Thanks for your answer.
I was thinking just like you by reading the previous comments. Why not simply
adding a parser function to do that?
Something like tt{{#unit:1000 ft}}/tt. This will address both concerns
about the ''link'' syntax [[1000 ft]] and the problem that just using a regular
expression to discover quantities (as suggested in comment #25) will open the
risk of converting things that look like units but aren't really. As an
example, any reference to the IEEE's ''802.11g'' standard shouldn't be
converted!
Concerning your last remark:
Changing based on user preference is unlikely,
but who knows.
If not on user preference, under which criteria should we perform that
conversion?
--
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 21469] Grant MediaWiki NS access to all users
https://bugzilla.wikimedia.org/show_bug.cgi?id=21469 MZMcBride pub...@mzmcbride.com changed: What|Removed |Added CC||pub...@mzmcbride.com --- Comment #2 from MZMcBride pub...@mzmcbride.com 2009-11-19 19:34:58 UTC --- Not sure about namespace restrictions, but it's probably easier to just give the user user group the editinterface right, no? -- 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 235] Auto unit conversion
https://bugzilla.wikimedia.org/show_bug.cgi?id=235
--- Comment #29 from Aryeh Gregor simetrical+wikib...@gmail.com 2009-11-19
19:35:11 UTC ---
I was thinking something like {{#unit:1000 ft|m}} or such, like the current
enwiki parser functions. That's not really what the original request asks for,
though, you're right. But as I said, no one with commit access seems very
interested in developing this or reviewing it.
--
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 21571] New: Enable that admins can grant flood flag for other users
https://bugzilla.wikimedia.org/show_bug.cgi?id=21571 Summary: Enable that admins can grant flood flag for other users Product: Wikimedia Version: unspecified Platform: All URL: http://simple.wikipedia.org/wiki/Wikipedia:Simple_talk#F lood_flag OS/Version: All Status: NEW Keywords: shell Severity: enhancement Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: barras...@web.de Hi there! We discussed here: http://simple.wikipedia.org/wiki/Wikipedia:Simple_talk#Flood_flag to enable the ability for admins to grant flood flag not only to admins themselves, but rather to give the admins the ability to grant it to every user. Please do it this way. The discussion looks like an agreement to enable this feature this way. However, if there is a way to do it that the flag expires one hour after granting it, so please do it this way, otherwise, it is ok if admins can just remove it. Kind regards [[m:User:Barras]] -- 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 21429] Arabic double diacritics presentation
https://bugzilla.wikimedia.org/show_bug.cgi?id=21429 Philippe Verdy verd...@wanadoo.fr changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #3 from Philippe Verdy verd...@wanadoo.fr 2009-11-19 19:48:24 UTC --- Isn't the U+FC61 a compatibility character whose normalization excludes decomposition and recombinations under NFD/NFC canonical equivalences? If some Arabic fonts do not support two successive diacritcs as recommended by Unicode, and only support the decomposable compatibility characters, these fonts are really bogous and should be avoided. But the problem is not there, see below. If the character is not a canonical equivalent to the two diacritics, it must not be altered (even if it's not recommended). In other words, MediaWiki must just apply the NFC normalization, but NOT the NFKC normalisation. When I look at the UCD, it reveals that U+FC61 decomposes as [isolated] U+0020 U+064F U+0651 Which means that this is just a compatibility decomposition, and not a canonical decomposition (note also that the decomposition adds an extra space, which in newer documents should rather be a non-breaking space instead of a regular space, to avoid side effects that are possible with whitespace compressions in HTML and XML). Note also that the space still prohibits reordering. I see no reason then, why Mediawiki would choose to convert U+FC61 incorrectly to U+064F U+0651 (stripping the [isolated] compatibility specifier and one space). And also no reason why it would recombine U+064F U+0651 (adding the leading space and an inexistant [isolated] form) into U+FC61 in the editor. The same reason should be applied to all the other Arabic compatibility characters (with implicit letter forms) that should be avoided in actual arabic text, unless there is a strong reason to display the character in isolation with a specific form distinct from the normal Arabic presentation rules. -- 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 21358] Filter reacted but it shouldn't
https://bugzilla.wikimedia.org/show_bug.cgi?id=21358 --- Comment #8 from Andre Koopal an...@molens.org 2009-11-19 20:09:05 UTC --- reproducing is hard, as the error doesn't appear always. Given the fix that Abigor did, it seems that the problem is in the lcase-function. But I understand debugging will be 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 21469] Grant MediaWiki NS access to all users
https://bugzilla.wikimedia.org/show_bug.cgi?id=21469 MZMcBride pub...@mzmcbride.com changed: What|Removed |Added Severity|enhancement |major Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from MZMcBride pub...@mzmcbride.com 2009-11-19 20:15:35 UTC --- This change allowed all users to edit and register accounts. Needs to be fixed or reverted as soon as possible. Re-opening bug. -- 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 16257] install script and text browser support
https://bugzilla.wikimedia.org/show_bug.cgi?id=16257 Max Semenik maxsem.w...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Max Semenik maxsem.w...@gmail.com 2009-11-19 20:23:54 UTC --- There's nothing wrong about allowing JavaScript as long as pages degrade gracefully for browsers without JS. The installer does its job without JS, though of course you will be unable to gain advantage of all those niceties JS provides. -- 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 17762] Show/hide further email conf. options depending on the E-mail features (global) option
https://bugzilla.wikimedia.org/show_bug.cgi?id=17762 Bug 17762 depends on bug 16257, which changed state. Bug 16257 Summary: install script and text browser support https://bugzilla.wikimedia.org/show_bug.cgi?id=16257 What|Old Value |New Value Status|NEW |RESOLVED Resolution||INVALID -- 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 21358] Filter reacted but it shouldn't
https://bugzilla.wikimedia.org/show_bug.cgi?id=21358 --- Comment #9 from Abigor abi...@forgotten-beauty.com 2009-11-19 20:26:17 UTC --- I will write down what I did so you could reproduce it, I also have the filter code for the moment that the error occurred (before my fix) But that will be something I do when I have the time, could take a day or two. -- 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 21469] Grant MediaWiki NS access to all users
https://bugzilla.wikimedia.org/show_bug.cgi?id=21469 MZMcBride pub...@mzmcbride.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from MZMcBride pub...@mzmcbride.com 2009-11-19 20:31:43 UTC --- Fixed by Andrew.[1] [1] http://wikitech.wikimedia.org/index.php?diff=23750oldid=23749diffonly=1 -- 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 235] Auto unit conversion
https://bugzilla.wikimedia.org/show_bug.cgi?id=235 Sylvain Leroux sylv...@chicoree.fr changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #30 from Sylvain Leroux sylv...@chicoree.fr 2009-11-19 21:15:50 UTC --- Sounds definitively feasible. I will take a closer look at this by the end of the week. -- 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 21572] New: save referencing the newest version of page using one of its history id
https://bugzilla.wikimedia.org/show_bug.cgi?id=21572 Summary: save referencing the newest version of page using one of its history id Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: easy, i18n Severity: enhancement Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: gangl...@torg.is CC: gangl...@torg.is note: This feature request might be a duplicate. I spend an half an hour searching an old request fromm an contributor in a Wikipedia using non Basic Latin UTF-8 characters. Dear friends; Last week I saw a link to a page from the Wikipedia in Hebrew on facebook. It was a public computer using Internet Explorer on a Windows in the State Library of Bavaria in Mubich. I was neither able to click on the link nor to copy the link from facebook and paste it to the url line in IE because to improper UTF-8 handling of involved programs and operating system. As you know there are a lot of redirecting special pages as [[Special:MyPage]], [[Special:MyTalk]] and some spelling variants for many other special pages. Today http://en.wikipedia.org/w/index.php?title=User_talk:Gangleri/tests/sandbox/squaresoldid=307411828 is a permanent link to [[user_talk:Gangleri/tests/sandbox/squares]] a shorter version is http://en.wikipedia.org/w/index.php?oldid=307411828 as implemented in [[wikt:yi:MediaWiki:Gadget-ShortLink]] see also http://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_User_scripts/Requestsoldid=190868168#toolbox_item_or_tab_with_a_short_format_link_using_.C2.AB_oldid.3D.7B.7BREVISIONID.7D.7D_.C2.BB One solution to lates versions could be the implementation of newest as in a constructed link http://en.wikipedia.org/w/index.php?diff=307411828newest (I have no clue what this link generates today). Because I experienced lots of problems posting links at facebook containing ampersands I would suggest to implement a save redirecting special page [[Special:Newest/190868168]]. Best regards Reinhardt [[user:Gangleri]] -- 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 21572] save referencing the newest version of page using one of its history id
https://bugzilla.wikimedia.org/show_bug.cgi?id=21572 Platonides platoni...@gmail.com changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #1 from Platonides platoni...@gmail.com 2009-11-19 21:22:57 UTC --- I think you would want to use http://en.wikipedia.org/w/index.php?curid=23897925 instead. -- 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 21572] safe referencing the newest version of page using one of its history id
https://bugzilla.wikimedia.org/show_bug.cgi?id=21572 lɛʁi לערי ריינהארט gangl...@torg.is changed: What|Removed |Added Summary|save referencing the newest |safe referencing the newest |version of page using one of|version of page using one of |its history id |its history id --- Comment #2 from lɛʁi לערי ריינהארט gangl...@torg.is 2009-11-19 21:39:54 UTC --- (In reply to comment #0) ... implement a save redirecting special page ... should read ... implement a *safe* redirecting special page ... Thanks Platonides; your link worked a few seconds ago; after a minor edit it generates a bad title. http://en.wikipedia.org/w/index.php?oldid=306683475 is valid but http://en.wikipedia.org/w/index.php?curid=306683475 is *not*. note: due to caching you may still see an outdated result. PLease reload your cache or try again tomorrow. -- 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 21572] safe referencing the newest version of page using one of its history id
https://bugzilla.wikimedia.org/show_bug.cgi?id=21572 --- Comment #3 from Platonides platoni...@gmail.com 2009-11-19 21:45:05 UTC --- But http://en.wikipedia.org/w/index.php?curid=23897925 *is* oldid is a revision number. curid is a page number. Don't mix both numbers. curid will refer to the same page regardless of its name (should follow even accross renames) oldid refers to the a page content (ie. a revision). -- 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 21573] New: chained autopromote fail
https://bugzilla.wikimedia.org/show_bug.cgi?id=21573 Summary: chained autopromote fail Product: MediaWiki Version: 1.15.0 Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: jbreid...@hotmail.com i am using: MediaWiki 1.15.0 PHP 5.2.11 (apache2handler) MySQL 5.0.87 on a rhel LAMP server. I am hoping someone has tried this before. my users are authenticated and groups retrieved from ldap, i am using autompromote to map those users to local groups from their ldap groups. here is my autopromote pre $wgAutopromote = array( bureaucrat = array(|,array(APCOND_INGROUPS, be-hro-dev), array(APCOND_INGROUPS, be-pun-dev), array(APCOND_INGROUPS, div-rd-1), array(APCOND_INGROUPS,quickdesign-writers), array(APCOND_INGROUPS, div-rd-2)), reviewer = array(|,array(APCOND_INGROUPS,bureaucrat), array(APCOND_INGROUPS, sysop)), editor = array(APCOND_INGROUPS, sysop) ); /pre It seems the first autopromote works but the userlist page does not show the user in the group, neither does the userrights page. in the page source however i do see, pre var wgUserGroups = [div-rd-1, *, user, bureaucrat]; /pre only the userlist and userrights page i only see the div-rd-1. also looking through the autompromote code the iterations through this array do not take into account any groups that may get promoted during the loop, only what was assigned to the user at the time the check was run. any thoughts or suggestions? -- 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 #145 from Roan Kattouw roan.katt...@gmail.com 2009-11-19 22:13:25 UTC --- (In reply to comment #144) Some SQL engines (like Oracle, Sybase, Informix, but probably not all index formats supported in various versions of MySQL) also store the rowID's of the component tables from which columns are extracted in the SELECT clause, in order to allow the columns under the read cursor to be updatable, but won't do that for columns computed from expressions, which are not updatable. This just requires opening the cursor FOR UPDATE (and sometimes, you can also limit the list of table columns that need to be updated within the cursor loop, which remains open during the transaction, in order to minimize the extra storage for dependant rowID's). Let's not make assumptions about individual DB engines here, but use SQL queries that unambiguously state what we want without relying on such behavior. About the whole page ID thing: as long there's a sorting tiebreaker of some kind making every entry unique (not necessarily visibly unique in the UI, just unique to the software), paging will be fine. Whether that tiebreaker is the page ID or the page title or the water level in the San Francisco Bay at the time of the page creation measured in 128ths of inches doesn't matter all that much from the implementation side, although of course only the second is remotely understandable for 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 21574] New: Add possibility to create 303 See Other redirects
https://bugzilla.wikimedia.org/show_bug.cgi?id=21574 Summary: Add possibility to create 303 See Other redirects Product: MediaWiki Version: 1.16-svn Platform: All OS/Version: All Status: NEW Keywords: need-review, patch Severity: enhancement Priority: Normal Component: Redirects AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: denny.vrande...@kit.edu Created an attachment (id=6805) -- (https://bugzilla.wikimedia.org/attachment.cgi?id=6805) Patch that creates the enhancement The current software only allows redirects with 301 and 302 (and does not even document that, ts). This patch adds also the possibility to create 303 redirects. This is required so that extensions can be compatibel to W3C standards on resource representation serving, as described in Web Architecture http://www.w3.org/TR/webarch/ and especially TAG issue 14 on httpRange http://www.w3.org/2001/tag/issues.html#httpRange-14 The patch also allows to set the response code on redirects to 303. It could be extended for even more redirect codes, but this seems not required yet (I searched the bugzilla list). -- 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 21575] New: HTTP server at download.wikipedia.org should set Last-Modified header
https://bugzilla.wikimedia.org/show_bug.cgi?id=21575 Summary: HTTP server at download.wikipedia.org should set Last- Modified header Product: Wikimedia Version: unspecified Platform: All URL: http://download.wikipedia.org OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Downloads AssignedTo: tf...@wikimedia.org ReportedBy: jcsahnwa...@gmail.com lighttpd at http://download.wikipedia.org currently does not set the Last-Modified header in the response for most files. Example: the response to a GET or HEAD request for http://download.wikipedia.org/enwiki/latest/enwiki-latest-interwiki.sql.gz does not include a Last-Modified header, but the response for http://download.wikipedia.org/enwiki/latest/enwiki-latest-interwiki.sql.gz-rss.xml does. The reason is probably this: If there is no content-type set, we remove the Last-Modified header http://redmine.lighttpd.net/issues/1236 To fix this, it should suffice to add the following lines to the lighttpd config file: mimetype.assign = ( .gz = application/x-gzip, .bz2 = application/x-bzip ) The Last-Modified header would be helpful for many things, e.g. to set the correct timestamp for the local copy of the file and to use wget timestamping. -- 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 20812] Wikisource: IPs unable to flag articles as proofread
https://bugzilla.wikimedia.org/show_bug.cgi?id=20812 Snottygobble snottygob...@gmail.com changed: What|Removed |Added CC||snottygob...@gmail.com --- Comment #29 from Snottygobble snottygob...@gmail.com 2009-11-19 23:53:40 UTC --- As I understand it, Thomas objects to this proposal and patch because the new pagequality tag integrates the various language domain implementations, allowing the automatic maintenance of pages like http://wikisource.org/wiki/Wikisource:ProofreadPage_Statistics. This page compares the progress of different domains, and therefore must use the same metric for each domain. Otherwise it is useless. The proposed patch changes how progress is measured for a single domain, and thus would invalidate the entire integration. This is why Thomas opposes it. The choices, then, are: 1. Thomas could patch all of the domains... but this would require consensus across all of them, not just de.wikisource; 2. de.wikisource can withdraw from the integrated page quality system and fix their problem. No patch is needed for this; they need only revert their local Javascript to a version that does not use the pagequality tag. -- 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 #146 from Philippe Verdy verd...@wanadoo.fr 2009-11-20 00:11:53 UTC --- I did not make assumptions about SQL engines, because this message exactly says the opposite: there are varieties there, and Mediawiki could/should also work with other SQL backends then just MySQL, even if it is open-sourced, but mainly supported now by Sun which has its own strategies on it. But I wanted to really note that the page id had no use for sorting results, given that we really want to sort by full page name, as a single entity or split in two parts if we consider the namespace... And may be into more parts, if we consider the subpage names that are also part of the full page name by specially tailoring the / character in the collation order so that a/c will still sort with sort with a, and not after ä or a!, by giving a less than minimum primary weight to the / character used as subpages separator (a value even before characters with default-ignorable primary weight values). Another way to perceive multicolumn hierarchical sort keys is to think about them as if they were separated in a single string by an implicit (non-coded) character with a non null but less than minimal primary weight value lower than default ignorable characters. In UCA impelmentations there a reserved weight for this function (fully ignorable characters get the null primary weight which does not participate at all to the computed collation key, this invisible character takes the next weight, and then the default-ignorable characters come just after, followed by combining characters, then whitespaces, and then generally in the order: punctuation and symbols, numerals, letters and ideographs). This implicit separator may be the same as the one for separating series of weight at each level within the same source string (but many UCA implementations, including ICU, do not need to encode this separator in the computed multilevel collation key, as they allocate the collation weights in non overlapping numeric ranges where the highest one is used for the primary weights ; but they still maintain a reserved value for easily computing multicolumn sort keys by simple concatenation with the encoded binary primary weight for this the column separator). Note also that in UCA, some groups of distinct strings, whose collation key are computed at the maximum level (generally level 4 with the DUCET, but possibly longer in collations tailored for some complex languages), can still have the same collation key: this will be true if the stricts contain different characters, but they are still canonically equivalent (i.e. they have the same NFC form). One string in each subgroup will be in NFC form, the others are in alternate non canonical forms and may even be longer): It is not a problem for language-sensitive collation, but effectively this sometimes requires adding a final binary comparison between the Unicode-encoded strings, to make sure that the sort order will be stable across database updates (such comparison needs not be stored in the collation key itself, given that we will still retreive the full page name from the database, for displaying them, and not just the collation key which is just used in the ORDER BY clause. -- 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 3922] links are not properly rendered in a BiDi category list
https://bugzilla.wikimedia.org/show_bug.cgi?id=3922
Philippe Verdy verd...@wanadoo.fr changed:
What|Removed |Added
CC||verd...@wanadoo.fr
--- Comment #24 from Philippe Verdy verd...@wanadoo.fr 2009-11-20 00:23:17
UTC ---
Why don't you simply place each captegory within a basic span.../span and
then separate them using (space,pipe,space) separators ? The BiDi algorithm
does not reorders text fragments across distinct strings in distinct elements
which remain in their own unbroken run of glyphs ?
You don't need to use BiDi control overrides (and they are officially NOT
recommanded in HTML).
So this should work (no need to even test the site's locale directionality, or
if there are mixed scripts in the visible category names) :
$t = 'span' . implode('/spannbsp;| span', $wgOut-mCategoryLinks) .
'/span';
--
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 21544] Text/URLs not wrapped in commit summary in Chrome 4
https://bugzilla.wikimedia.org/show_bug.cgi?id=21544 Reedy s...@reedyboy.net changed: What|Removed |Added Summary|URLs not wrapped in commit |Text/URLs not wrapped in |summary in Chrome 4 |commit summary in Chrome 4 --- Comment #2 from Reedy s...@reedyboy.net 2009-11-20 00:49:12 UTC --- 59260 which is just text is the same -- 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 21576] New: Installation gives misleading error message on empty wikiuser password
https://bugzilla.wikimedia.org/show_bug.cgi?id=21576 Summary: Installation gives misleading error message on empty wikiuser password Product: MediaWiki Version: 1.15.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: Normal Component: Installation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: anton...@googlemail.com Environment: -- Windows XP -- Apache 2.2 -- PHP 5.3.1 -- PostgreSQL 8.4.1 Use-case: (1) Running the mediawiki/config/index.php setup script. (2) Leave the password for the new wikiuser account empty. (3) Enter superuser info. (4) Run script. What happens: (A) First part of the script goes fine because that's done with the superuser account. (B) Creates wikiuser account with password fine (checked with PostgreSQL admin tool). (C) But when tries to connect to DB with this account it fails. (D) But the script keeps running! (E) Gets confused at version check and breaks. A couple of notes... (*) There seems to have been a bug with PHP 5.3 and MediaWiki 14.x.y related to the second PostgreSQL version check. Unfortunately this scenario looks exactly the same as that one which can easily mean you spend an hour or so following the wrong thread (I'm speaking from experience here). (*) The instructions on the setup page are a little misleading. It certainly reads as though you EITHER enter the super-user or a wikiuser account. This is why I left the password field empty (I don't think that passwords are a great idea). Suggested fix... (1) Make it clear on the installation screen that a password for wikiuser is required (I'd suggest some text but I can't get back to that screen now the install is completed). (2) Do some validation to ensure that that is the case. (3) If the connection to the DB fails then break the script there with a helpful error message. -- 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 #147 from Andrew Dunbar hippytr...@gmail.com 2009-11-20 01:50:55 UTC --- MySQL does support CLDR/UCA collation and I believe it to be fast. The reason we don't use it is that MySQL does not support the full range of Unicode whereas MediaWiki does. MySQL is limited to the BMP (Basic Multilingual Plane). I believe for this reason MediaWiki does not even use any of MySQL's support for UTF-8 but instead stores all text as binary and handles UTF-8 issues itself. The feature request for non-BMP support in MySQL seems to be this one marked low priority with only 2 people watching it: http://forge.mysql.com/worklog/task.php?id=1213 -- 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 21577] New: Let GeoLite handle different targets for chapters
https://bugzilla.wikimedia.org/show_bug.cgi?id=21577
Summary: Let GeoLite handle different targets for chapters
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Keywords: patch
Severity: enhancement
Priority: Normal
Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: thomas.dal...@gmail.com
Created an attachment (id=6806)
-- (https://bugzilla.wikimedia.org/attachment.cgi?id=6806)
Patch - see description
This patch should allow different fundraising banners to link to different
chapter landing pages. To get the banners to do what we want in the UK, the
following will need to be added to wherever the globals for meta are defined:
$wgChapterTargets['Help_Us_Change_the_World']['uk']=true;
('uk' may need to be replaced by whatever the geoip calls the UK, use whatever
is used as the key in $wgChapterLandingPages)
The same kind of line should be added for any specific target page that exists
for a specific chapter. If the array value doesn't exist, it defaults to the
standard chapter page (as happens currently).
NB: THIS CODE IS UNTESTED (I don't have a local system with this extension
installed and it is far too complicated to set one up and my PHP-fu is
insufficient to guarantee it will work by eye)
--
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 #148 from Philippe Verdy verd...@wanadoo.fr 2009-11-20 04:25:06 UTC --- May be it's low in their priority, but with the development of Unicode and the now ongoing efforts to add now many more characters in plane 1 (notably lots of symbols, including common things like circled letters and numbers) and 2 (ideographs) for modern use, this position will become unmaintainable, and the need for extending the MySQL UTF-8 support will increase. After all, MySQL is now controled by Sun, which is an active member of Unicode Technical Commity, and even Sun will want a better interfaction with its Java platform that has excellent Unicode implementation and is used as a reference platform (even before the newest algorithms are ported to C/C++). ICU is also supported by IBM that has a strategic need in C/C++, Java, and intergration in web services (both on the server- and client-side of applications). Here also IBM wants itegration with its dB2 SQL platform but has siognificant offers over MySQL. Both companies (also Apple, Oracle, and many others) are highly engaged in the Unicode development process, internationalisation, and want support for their platforms (including in China, where currently MySQL will not be an option, as long as full support of Unicode will not be there). in fact, extending the support to the missing plnes is now a small effort in comparison to what has already been made by them. And another refernce platform (Perl) can also help generate the missing code or data tables that are needed (the PHP platform makes no efforts itself, as its Unicode support completely depends on ICU now, which is now a reference library that is becoming nearly universal on all platforms, with the except of Windows where Microsoft has rewritten everything in its CLR for .Net). May be MySQL will sooner or later replace its own implementation simply by integrating ICU, to save the collaborative efforts... The only seriously missing development for collation for now is on the client side: we still lack a good support of collation in Javascript (which just as a string.localeCompare(string) method with an unspecified collation table, and incompatible implementations across browsers with lots of bugs.): the few demonstrations that I have seen need to use server-side components to actually collate or process the Unicode data through AJAX! I think that this will come when JSP server-side applications will start to want Collators without depending on native libraries (that cannot be deployed easily from servers to servers, or over computing grids). Collator factories should become as universal in I18N framewaorks, as it is now for translation resource bundles, date/time formats, case mappings, encoding convertors, and regular expressions. So are there voluntaries to implement it in MediaWiki using its native PHP platform (through the intl10n library), independantly of MySQL (which is just a backend, from which MediaWiki should not heavily depend exclusively). -- 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 19092] Diffs of small changes can be misleading
https://bugzilla.wikimedia.org/show_bug.cgi?id=19092 Philippe Verdy verd...@wanadoo.fr changed: What|Removed |Added CC||verd...@wanadoo.fr --- Comment #2 from Philippe Verdy verd...@wanadoo.fr 2009-11-20 04:37:33 UTC --- The dif is not that big. A single paragraph, formatted as a single line, is plit in two separate lines, and it is normal that these two lines are tagged in diffs. This is the normal behavior of Unified diffs which compares full lines. The actual result in fact displays more granular differences with coloring, isn't it enough ? You seem to want that MediaWiki automatically splits lines into several parts to show the differences and similitudes between fragments of lines. I don't think it will be very useful (and in many cases it will just add many more differences, on very small fragments. -- 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
