[Bug 164] Support collation by a certain locale (sorting order of characters)
https://bugzilla.wikimedia.org/show_bug.cgi?id=164
--- Comment #187 from Philippe Verdy 2010-07-24 06:17:18
UTC ---
(In reply to comment #185)
> 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.
This does not require any change in the schema. This can be made immediately by
MediaWiki developers and will not influence the developement of all corrections
needed for bug #164 itself.
The unique index just has to include the cl_from field (whatever it contains,
it is already the unique ID of the page, and it is already stored). Only the
SQL queries and the HTTP requests have to be able to specify this cl_from field
separately.
Tacking it in the sortkey was a bad decision made by "lazy" developers before
they realized that storing a separate cl_from field was necessary. It just
polluted the indexes and had the bad effect of truncating more precious space
for correctly sorting some pages.
Drop this tacking immediately in the PHP code: the cl_sortkey is only intended
to store the clear-text sortkey "hint" specified in {{DEFAULTSORT:sortkey}} or
[[category:...|sortkey]] to override the sort order, and this clear-text
sortkey is not really a true sortkey but a sort hint to override the default
sort order.
For example in people's names whose page name is "FirstNames LastName" but that
we want to sort as if they were "LastName, FirstNames" by indicating only
{{DEFAULTSORT:LastName !}} (it should not needed to include the FirstNames in
the wiki text, as this sort hint will not be unique and the group of pages
using the same hint will still need to sort within this group using their
natural order). Even in that case, there's no need to bogously tack the cl_from
field in the stored field.
--
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 16275] Editing page for Wikipedia talk pages: Add "save with signature" button to "Save Page" "Show Preview" and "Show Changes" group
https://bugzilla.wikimedia.org/show_bug.cgi?id=16275 Max Semenik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Max Semenik 2010-07-24 06:14:16 UTC --- We're working on LiquidThreads instead, which will not have such 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 24521] New: "code error!" shouldn't be hard coded
https://bugzilla.wikimedia.org/show_bug.cgi?id=24521 Summary: "code error!" shouldn't be hard coded Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Language converter AssignedTo: philip@gmail.com ReportedBy: liang...@gmail.com A message should be used. It's $mManualCodeError of class ConverterRule in LanguageConverter.php. -- 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 #186 from Philippe Verdy 2010-07-24 05:53:30
UTC ---
(In reply to comment #183)
> 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.
That'a a bad assumption : even the highest quality collations will need to be
updated from time to time:
- Unicode evolves and new characters get encoded (new versions are published
about every 1-2 years after synchronization and final balloting at both ISO WG2
and the UTC.
- The content of the Unicode DUCET is NOT stable: characters are inserted in
the sequence so that the full list of collation weights needs to be offseted
where the new characters get inserted.
- Collations for languages get corrected. We should be able to upgrade these
rules when the CLDR project produces new tailorings (CLDR updates are published
separately, about every 1-2 years.)
These corrections may be rare (every few months), but when they will occur, any
upgrade could take many hours that could horce the site to go offline when
recomputing sortkeys, or NO correction will be possible. Upgrading "in place"
is effectively what I proposed, but how will you track which pages need to to
reindexed?
A collation ID in the stored index can really help determine which collation
rule was used to generate the stored sortkey; In addition it will allow to
support multiple collations. This is the mean by which the "in place"
recomputing can be safely be done.
Note: truncating the sortkeys will ALWAYS be needed, just because the database
column will still have a length limit. Truncating is not so bad anyway,
because:
- the compact binary sequence of primary collation weights, that starts the
sort key will be at the begining of the sort key. Further length is used to
store the compacted sequence of secundary collation weights, then the sequence
of ternary collation weights.
- if truncation occurs, the effect will be that only the smallest differences
will not be represented.
But if you accept to store only non-truncated sort keys, you'll still have the
case where some pages will have some long name, plus the case where someone
will have indicated for that page a very long {{DEFAULTSORT:sortkey}} or very
long text in the second parameter of [[category:...|sortkey]]. To avoid this:
- page names already have a length limit. This also limits the length of sort
keys computed from only them
- we should already truncate the string given in {{DEFAULTSORT:sortkey}} or
{{category:..|sortkey]] so that the concatenation of this string and of the
page name can be used to compute the binary sortkey.
If you can accept arbitrary lengths, so go with it, but it will be unsafe and
your schema will not be able to put that in a sortable column (you'll be only
able to put it in a referenced BLOB, just like the the text of articles, and
databases can never sort external BLOB's)
Anyway you did not reply to the idea of first developin the parser functions
and test them. Developping the SQL schema extension should not be attempted
before at least the first function {{SORTKEY:text|locale|level}} has been fully
developed and tested on specific pages (it can be tested easily in tables).
And with just this function, it should be possible on specific wikis to use it
immediately to sort specific categories (for example by using templates using
that function).
The second function {{COLLATIONMAP:text|locale|level|clusters}} is not needed
immediately to develop the schema, but will be useful to restore the
functionality of headings. Headings don't need to be stored as they can be
computed on the fly, directly by reading sequentially the sorted result set
from the SQL query:
You can compute headings from the returned page names, or from the existing
stored "cl_sortkey" which should be used now ONLY to store the plain-text
specified in articles with {{DEFAULTSORT:sortkey}} and
[[category:...|sortkey]].
The existing cl_sortkey is just a forced "hint", it does not make the sort
order unique. Otherwise it should remain completely empty with the new schema.
It will always be locale neutral and will take precedence on the page name : to
sort the pages effectively, the content of the cl_sortkey content and the
pagename should be always concatenated inernally to compute the binary sortkey
for various 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 24520] Transwiki import source for ml.wikiquote.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=24520 p858snake changed: What|Removed |Added Keywords||shell CC||p858sn...@gmail.com Component|General/Unknown |Site requests --- Comment #1 from p858snake 2010-07-24 05:53:50 UTC --- Please show 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 24520] New: Transwiki import source for ml.wikiquote.org
https://bugzilla.wikimedia.org/show_bug.cgi?id=24520 Summary: Transwiki import source for ml.wikiquote.org Product: Wikimedia Version: unspecified Platform: All URL: http://ml.wikiquote.org OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: vss...@gmail.com CC: junu...@gmail.com, kirangop...@gmail.com Transwiki import sources for ml.wikiquote may please be defined. The following sites may be included http://en.wikiquote.org http://en.wikipedia.org http://ml.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 23037] New extension to automatically sign talk pages, or warn that the user has not signed
https://bugzilla.wikimedia.org/show_bug.cgi?id=23037 p858snake changed: What|Removed |Added Component|[other] |Extensions requests -- 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 23027] Abuse filter does not allow for use of old_text or old_html
https://bugzilla.wikimedia.org/show_bug.cgi?id=23027 --- Comment #3 from Andrew Garrett 2010-07-24 03:08:43 UTC --- It requires reparsing the old text, which in some cases can take tens of seconds. Of course, the old text has already been parsed at some point, but some engineering is needed to actually retrieve this parsed HTML from the appropriate cache. -- 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 8814] White border around thumbs
https://bugzilla.wikimedia.org/show_bug.cgi?id=8814 --- Comment #7 from entli...@gmx-topmail.de 2010-07-24 01:24:05 UTC --- Note that overflow:hidden can clip content if a heading contains a very long unbreakable word and there is a right float before it. With overflow:visible, content is pushed down the float, but not with overflow:hidden; it's clipped instead. If it's not worth this risk, I'd suggest to just remove the white borders. They may serve a purpose, but cause rendering inconsistencies (other floats like infoboxes don't have such borders), and many wikis (enwiki, dewiki, commonswiki at least) remove them locally 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 24519] RevDel'd transwikied edits may be blanked
https://bugzilla.wikimedia.org/show_bug.cgi?id=24519 p858snake changed: What|Removed |Added CC||p858sn...@gmail.com Component|General/Unknown |Revision deletion AssignedTo|wikibug...@lists.wikimedia. |jschulz_4...@msn.com |org | Product|Wikimedia |MediaWiki -- 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 24519] New: RevDel'd transwikied edits may be blanked
https://bugzilla.wikimedia.org/show_bug.cgi?id=24519 Summary: RevDel'd transwikied edits may be blanked Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: g33kd...@gmail.com See http://simple.wikipedia.org/w/index.php?title=Daniel_Tosh&action=history, and http://en.wikipedia.org/w/index.php?title=Daniel_Tosh&action=history. Two edits in the en history show up as empty blank ones on simple's history due to being RevDel'd. I think that the deleted status should show for consistency. -- 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 19866] border color of thumbnails on colored backgrounds
https://bugzilla.wikimedia.org/show_bug.cgi?id=19866 entli...@gmx-topmail.de changed: What|Removed |Added CC||entli...@gmx-topmail.de --- Comment #3 from entli...@gmx-topmail.de 2010-07-23 23:23:56 UTC --- r53628 doesn't fix anything because this bug (essentially a dupe of bug 8814) is about borders, not backgrounds. Note that the problem is no longer visible at dewiki because the workaround from [[de:MediaWiki:Monobook.css]] has been copied to [[de:MediaWiki:Vector.css]]. -- 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 24474] New Thread is added in the wrong DOM element
https://bugzilla.wikimedia.org/show_bug.cgi?id=24474 Adam Miller changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Adam Miller 2010-07-23 22:52:54 UTC --- Fixed in r69821. -- 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 24183] Tall characters sometimes get cut off in the sidebar
https://bugzilla.wikimedia.org/show_bug.cgi?id=24183 entli...@gmx-topmail.de changed: What|Removed |Added CC||entli...@gmx-topmail.de --- Comment #3 from entli...@gmx-topmail.de 2010-07-23 22:39:27 UTC --- Somehow related to bug 24367. -- 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 24367] overflow:hidden on list items clips their marker boxes
https://bugzilla.wikimedia.org/show_bug.cgi?id=24367 --- Comment #1 from entli...@gmx-topmail.de 2010-07-23 22:39:24 UTC --- Somehow related to bug 24183. -- 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 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Bawolff 2010-07-23 22:38:50 UTC --- fixed in r69820 by making change tags not be displayed when those special pages are transcluded into another page. -- 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 24518] New: Barely legible colors for lang=lisp
https://bugzilla.wikimedia.org/show_bug.cgi?id=24518 Summary: Barely legible colors for lang=lisp Product: MediaWiki extensions Version: any Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: Normal Component: SyntaxHighlight (GeSHi) AssignedTo: soxre...@gmail.com ReportedBy: eroom.ec...@gmail.com Created an attachment (id=7589) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=7589) screenshot of GeSHi syntaxhighligh lang=lisp See attached screenshot. The chosen colors for GeSHi's lisp syntax highlighing are very light on a white background, and are barely visible. (Google Chrome 5.0.375.86 on Ubuntu Linux 10.04) -- 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 1629] Section edit links showing up in wrong place
https://bugzilla.wikimedia.org/show_bug.cgi?id=1629 entli...@gmx-topmail.de changed: What|Removed |Added CC||entli...@gmx-topmail.de --- Comment #60 from entli...@gmx-topmail.de 2010-07-23 22:00:42 UTC --- Related to bug 8814. -- 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 24374] Create new usergroups at commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=24374 --- Comment #14 from DieBuche 2010-07-23 21:44:19 UTC --- I agree with cary, steward is probably a bit over the top & our local 'crats should be trustworthy enough. -- 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 24374] Create new usergroups at commons
https://bugzilla.wikimedia.org/show_bug.cgi?id=24374 DF changed: What|Removed |Added CC||wmdf...@gmail.com --- Comment #13 from DF 2010-07-23 21:37:25 UTC --- (In reply to comment #8) > You can use the meta group assigner to add groups to users that dont exist on > meta...(afaik) No, it is not possible but it has been requested on bug 12518 FWIW -- 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 8814] White border around thumbs
https://bugzilla.wikimedia.org/show_bug.cgi?id=8814 entli...@gmx-topmail.de changed: What|Removed |Added CC||entli...@gmx-topmail.de --- Comment #6 from entli...@gmx-topmail.de 2010-07-23 21:37:01 UTC --- See bug 16272 comment 1 for why the borders are there at all. But the desired effect (preventing h2 lines from connecting to floated thumbs) can be achieved in a simpler and more general way by applying overflow:hidden to the h2 elements. This would work for all floats, not just thumbnails, and also fix bug 1629, but has side-effects: * overflow:hidden does nothing in IE 6. If that's a problem, the desired effect can be achieved by triggering hasLayout. In IE 7, it works because overflow:hidden has become a hasLayout trigger. It finally works as it should in IE 8. * Headings would become invisible in IE/Mac, see bug 1629 comment 40 and http://l-c-n.com/IE5tests/overflow/#overflowblock. If that's a problem, it can be he hidden from this ancient browser. * Bug 1629 comment 38 is about unspecified problems with RTL and Firefox that would have to be looked into. Besides that, I wonder why every skin needs to contain a copy of this code. Can't this at least be consolidated in shared.css and commonPrint.css? At the German Wikipedia, we have the same workaround as in comment 5 scattered across the local skin-specific CSS files, and there is no consensus to put them in Common.css as long as it's scattered upstream. -- 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 24516] IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516 --- Comment #5 from Amir E. Aharoni 2010-07-23 21:01:30 UTC --- Excellent! Thank you! You could have marked it as fixed for all i care. -- 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 24516] IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516 --- Comment #4 from Derk-Jan Hartman 2010-07-23 22:54:48 CEST --- Changes deployed. Make sure to bypass all your browser caches and try again. (Only works with Javascript enabled, because of javascripted Operating System detection. -- 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 24516] IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516 --- Comment #3 from Derk-Jan Hartman 2010-07-23 22:45:23 CEST --- 1: Because the problem is not in MediaWiki, it is in the English Wikipedia 2: I'm doing it 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 24516] IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516 --- Comment #2 from Amir E. Aharoni 2010-07-23 20:37:03 UTC --- 1. If you acknowledge that a problem exists, why are you marking it as "invalid"? Windows sucks, but it's still the most popular system. 2. If it can be fixed as a Windows specific CSS hack - which was my intention in the first place - where can this be reported if not here? -- 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 24516] IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516 Derk-Jan Hartman changed: What|Removed |Added Status|NEW |RESOLVED CC||hart...@videolan.org Resolution||INVALID --- Comment #1 from Derk-Jan Hartman 2010-07-23 22:27:12 CEST --- Thinking about this again... This is because Windows doesn't have good routines to fallback to other fonts when the default font doesn't contain the glyph needed to render a character. The current .IPA class solves this for IE, but specifically NOT for other browsers, because these browsers also work on other platforms that do not have this problem. Linux has fontconfig, Mac OS has CoreText and Windows sucks :D So this should be a Windows specific CSS hack, and not an IE specific hack as it is now. But this is not part of the main software at all, so it doesn't belong in bugzilla. -- 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 24517] New: Usage of $this in static methods
https://bugzilla.wikimedia.org/show_bug.cgi?id=24517 Summary: Usage of $this in static methods Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Images and files AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: s...@reedyboy.net CC: gpaum...@wikimedia.org, bryan.tongm...@gmail.com, innocentkil...@gmail.com LocalFile.php and OldLocalFile.php In newFromKey() in both of the files, they have 2 uses of $this -- 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 24470] Enable NewUserMessage extension on lv.wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=24470 Rob Halsell changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Rob Halsell 2010-07-23 19:18:39 UTC --- Done and pushed live. You will need to set the inwiki settings you reference above. If there are any issues, please feel free to reply and re-open this bug. Thanks! -- 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 23372] Special:Code/nonexistentrepo/certain_actions cause fatals
https://bugzilla.wikimedia.org/show_bug.cgi?id=23372 Max Semenik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Max Semenik 2010-07-23 18:22:11 UTC --- Works fine for me on trunk, Wikimedia needs an update. -- 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 24455] Show number of revs with each status on the status page
https://bugzilla.wikimedia.org/show_bug.cgi?id=24455 Max Semenik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Max Semenik 2010-07-23 17:58:36 UTC --- Done in r69748. -- 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 --- Comment #1 from Casey Brown 2010-07-23 17:30:20 UTC --- Cary mentioned that it would be cool if we could obfuscate/"nospam" the list admin address by default (for example, $list list run by $admin-emails-with-mailto-to-"-owner" switched to $list run by $list-owner (at) lists (dot) wikimedia (dot) org). There are probably a few ways to go about this, so I'll just give you the information he gave me and let you guys figure out the best way. :-) I'm back with more questions... does anyone know where the variables are defined? (e.g. ) Is it possible to add new variables? And if we edit the default listinfo.html, will it get overwritten in the next update? kibble: 1) Mailman/HTMLFormatter.py 2) You can add new variables. 3) if you edit the listinfo template via the list's admin GUI or following the instructions at http://wiki.list.org/x/jYA9 they will not be overwritten in an update, but your new variable definitions in HTMLFormatter.py will be. -- 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 24516] IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516 Amir E. Aharoni changed: What|Removed |Added Severity|enhancement |normal -- 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 24516] New: IPA is displayed inconsistently in different browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=24516
Summary: IPA is displayed inconsistently in different browsers
Product: Wikimedia
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: amir.ahar...@mail.huji.ac.il
I tried reading the article [[Holam]] in the English Wikipedia in different
browsers on Windows XP anonymously. This article uses the template {{IPA}},
which displays the text in it as class="IPA".
Class IPA tries to set font-family to "Charis SIL", "Doulos SIL", Gentium,
GentiumAlt, "DejaVu Sans", Code2000, "TITUS Cyberbit Basic", "Arial Unicode
MS", "Lucida Sans Unicode", "Chrysanthi Unicode". I have Charis, Doulos,
Gentium, DejaVu Sans, Code2000, Arial Unicode MS and Lucida Sans Unicode
installed. This, however, doesn't work consistently in all browsers. Here are
the results that i see:
* Firefox 3.6.7 - The font is not Charis, but probably Arial or Arial Unicode.
The display is partly faulty: the character 'ɡ' after the character 'ˈ', for
example in 'ʔesˈɡoʁ", looks like a Greek gamma (this doesn't happen on Windows
Vista).
* Firefox 4 beta 1 - Similar to Firefox 3.6.7, but even worse: The character
'ɡ' looks like it's taken from a completely different font.
* Windows Internet Explorer 8 - Seems to display IPA correctly using Charis.
* Opera 10.53 - Doesn't have the "ˈɡ" problem, but the font is not Charis.
* Google Chrome 5 - Like Opera 10.53.
* Safari 4.0.5 - The font is not Charis. The 'ɡ' is displayed like in Firefox 4
beta 1, as if it is taken from a different font, but there's no "ˈɡ" problem.
In my vector.css i defined this: ".IPA { font-family: Charis SIL !important;
}". If i log in using my username Amire80, i see IPA correctly in the Charis
font in all browsers except Opera, which still doesn't show IPA as Charis.
Anonymous users, obviously, don't have this fix and most of them probably don't
know that they see incorrect characters.
It is possible, of course, that the problem is with browsers and with Windows
XP, but it will take time until all browsers are fixed and the font display of
Windows XP is probably not going to be fixed, even though the OS will probably
stay popular for a few more years. Is it possible to fix Wikipedia's CSS to
make IPA look better despite these bugs?
--
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 24515] New: IE Font Sizing Bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=24515
Summary: IE Font Sizing Bug
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: Normal
Component: Vector Skin
AssignedTo: tpars...@wikimedia.org
ReportedBy: m...@gmx.org
IE6+7+? causes problems when scaling font size from browser settings via 'view
> font size > bigger'. As result fonts are scaled hilarious big, e.g. compared
to google. This is due to a IE bug, but can be avoided by a CSS hack. The body
tag should scale fonts bei 100.01%. For testing puroses the following css code
can be added to 'Spezial:Mypage/vector.css'
body {
font-size : 100.01%;
}
Scaling steps are now much more comfortable
--
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 24513] * or # in first line of a Semantic MediaWiki Text property field does not get parsed as a list item
https://bugzilla.wikimedia.org/show_bug.cgi?id=24513 MZMcBride changed: What|Removed |Added CC||b...@mzmcbride.com Summary|* or # in first line of a |* or # in first line of a |Text property field does|Semantic MediaWiki Text |not get parsed as a bullet |property field does not get |point |parsed as a list item -- 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 24514] New: Update notification fires when it shouldn't
https://bugzilla.wikimedia.org/show_bug.cgi?id=24514 Summary: Update notification fires when it shouldn't Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: LiquidThreads AssignedTo: agarr...@wikimedia.org ReportedBy: amil...@wikimedia.org CC: amil...@wikimedia.org I've been noticing the update notification is being displayed even when I'm the only one making edits. This shouldn't fire when the new updates are from the current user and are therefore already on the page. -- 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 24513] * or # in first line of a Text property field does not get parsed as a bullet point
https://bugzilla.wikimedia.org/show_bug.cgi?id=24513 --- Comment #1 from Neill Mitchell 2010-07-23 16:33:31 UTC --- Here's the generated html for the above example: *Point 1 Point 2 Point 3 So for some reason the first line of the text field is not being parsed correctly. -- 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 24475] Replying to a top level post is broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=24475 Adam Miller changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Adam Miller 2010-07-23 16:28:34 UTC --- Fixed in r69760 -- 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 24513] New: * or # in first line of a Text property field does not get parsed as a bullet point
https://bugzilla.wikimedia.org/show_bug.cgi?id=24513 Summary: * or # in first line of a Text property field does not get parsed as a bullet point Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: Semantic MediaWiki AssignedTo: mar...@semantic-mediawiki.org ReportedBy: mitchell_ne...@hotmail.com Hi. If I have: * Point 1 * Point 2 * Point 3 in a SMW Text property field the first * is not parsed. It gets displayed as a raw *. The 2nd and 3rd do get displayed as bullet points. The same is true for #. You only get the number from the second line on. Interestingly, looking at the HTML, I see that the Point 2 Point 3 are wrapped in a whereas Point 1 is 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 24512] New: Collection uses curl_*() functions instead of Http::*() functions
https://bugzilla.wikimedia.org/show_bug.cgi?id=24512 Summary: Collection uses curl_*() functions instead of Http::*() functions Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Collection AssignedTo: supp...@pediapress.com ReportedBy: roan.katt...@gmail.com MediaWiki has an Http class (see includes/HttpFunctions.php) wrapping cURL which falls back to fopen() if cURL is unavailable and throwing a helpful exception if neither is available. On the other hand Collection uses curl_*() functions directly. This doesn't allow for fallback to fopen() and doesn't display a helpful exception when cURL is unavailable but causes an opaque fatal error which has to be dug up from the error log. -- 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 4858] Thumbnail image not right-justified on some browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=4858 Derk-Jan Hartman changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- 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] bugs.wikimedia.org no longer redirects
https://bugzilla.wikimedia.org/show_bug.cgi?id=24499 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #3 from Roan Kattouw 2010-07-23 12:27:22 UTC --- Looks like kaulen is only redirecting https://bugs to bugzilla but not redirecting http://bugs . The HTTPS redirect fails because the cert is only valid for bugzilla.wm.o I think this could be solved with the following redirect chain: https://bugs.wikimedia.org --> http://bugs.wikimedia.org --> https://bugzilla.wikimedia.org or, if that's easier, redirect http://bugs.wikimedia.org to http://bugzilla.wikimedia.org which already redirects to https -- 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] bugs.wikimedia.org no longer redirects
https://bugzilla.wikimedia.org/show_bug.cgi?id=24499 MZMcBride changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from MZMcBride 2010-07-23 12:22:57 UTC --- http://bugs.wikimedia.org now returns a "It works!" message. https://bugs.wikimedia.org redirects, but has an SSL certificate warning that the user has to bypass. -- 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] Do not output empty portlets
https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 --- Comment #7 from Roan Kattouw 2010-07-23 11:04:39 UTC --- (In reply to comment #6) > Special pages have also empty "Actions" and "Views". > > Why should user using agent without CSS see things he doesn't need to see at > all? Didn't we want to simplify things? Why do we out of sudden return useless > things we never used to return? > Yes, but there are scripts manipulating these portlets as explained previously. > We should care about the validity first. If something isn't valid, it makes > more difficult to convert it or its displaying might be rejected. Don't think > only about "all browsers you know" - there are not only browsers, there are > also random other tools, which rely or depend on validity. > I have a very very hard time imagining how a browser could possibly choke on an empty in any way, shape or form. It makes zero sense for a browser implementor to specifically enforce this requirement, because being tolerant is easier, and programmers are lazy. In general, yes, I agree that validity is important, but I believe we can make exceptions for such utterly brain-dead things as requiring (not saying "you shouldn't do this" but saying "you MUST NOT do this, validation will FAIL if you do this") that s not be empty. HTML5 has realized this and has removed this requirement. > We should also care about optimalization - why should user load unnecessary > and > useless data, which are hidden and won't be used? Not everybody is sitting in > USA on optical cable, you know? Lot of people still pay a lot per kB, not > small > monthly flat fees. > One empty portlet takes 158 bytes (before gzip). By contrast, the HTML of the enwiki main page is 57,629 bytes (before gzip, in Vector; Monobook is 406 bytes shorter). There are bigger fish to fry here, such as the many tags,
[Bug 24511] New: 'No matching log entries' message is confusing
https://bugzilla.wikimedia.org/show_bug.cgi?id=24511 Summary: 'No matching log entries' message is confusing Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: liang...@gmail.com If a page was protected a long time ago (earlier than the logging system) and someone tries to edit it, a message saying 'No matching log entries' appears above the text box. This may make users confused. -- 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] Do not output empty portlets
https://bugzilla.wikimedia.org/show_bug.cgi?id=24500 Danny B. changed: What|Removed |Added Summary|Do not output variant |Do not output empty |portlet for languages |portlets |without variants| --- Comment #6 from Danny B. 2010-07-23 10:12:43 UTC --- (In reply to comment #5) > (In reply to comment #3) > > Please read carefuly. It is not only about empty . > > > > The entire empty portlet should not be there at all. > > > > Why should e.g. be there "Variant" portlet in languages, which do not use > > variants? Etc. > > > This specific argument make sense: the variant portlet should be safe to drop > for languages without variants. Repurposing bug. Special pages have also empty "Actions" and "Views". Why should user using agent without CSS see things he doesn't need to see at all? Didn't we want to simplify things? Why do we out of sudden return useless things we never used to return? > > Reopening, since this is not about the validity only. (Besides, untill we > > will > > serve HTML5 (and that might take long time, it won't be in few months), it > > still IS invalid.) > As outlined on one of the previous bug, we care more about not breaking > scripts > than we care about such a harmless invalidity: the rule that s can't be > empty is a stupid one that all browsers I know of ignore (which makes perfect > sense) ands which was dropped in HTML5, probably for these reasons (most of > the > premise of the simplified HTML5 markup is that it exploits tolerances in > existing browsers' HTML parsers, AFAIK) We should care about the validity first. If something isn't valid, it makes more difficult to convert it or its displaying might be rejected. Don't think only about "all browsers you know" - there are not only browsers, there are also random other tools, which rely or depend on validity. Besides, MediaWiki has variable to decide if you want to output HTML5 or XHTML1. That means, even if we will switch to HTML5 by default somewhen in far future, that we still have to take care about XHTML1. We should also care about optimalization - why should user load unnecessary and useless data, which are hidden and won't be used? Not everybody is sitting in USA on optical cable, you know? Lot of people still pay a lot per kB, not small monthly flat fees. The client scripts are the last piece in chain of website design, not the first. We can not build the house from the roof. Fix the scripts then, if they get broken by missing portlet. That is the proper solution. Not messing the HTML. The scripts are supposed to accomodate to HTML not HTML to scripts. -- 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 24505] Enable user group "editprotected" on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24505 --- Comment #6 from mayurkumar 2010-07-23 09:46:26 UTC --- Thank you very much -- 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 24505] Enable user group "editprotected" on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24505 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Roan Kattouw 2010-07-23 09:31:31 UTC --- Done. -- 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 24433] create protection level of confirmed user & sysopp in hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24433 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #11 from Roan Kattouw 2010-07-23 09:29:17 UTC --- Different way of accomplishing same thing has been requested at bug 24505, closing this one. See also bug 24505 comment #4 -- 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 24505] Enable user group "editprotected" on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24505 --- Comment #4 from Roan Kattouw 2010-07-23 09:28:47 UTC --- (In reply to comment #2) > O.k Install Either Bug 24433 or this present Bug 24505. We leave it up to a > sysadmin to arbitrarily decide which one to enable. We will be grateful to > bugzilla to resolve this issue a soon as possible. > I asked you to choose yourself, but if you really want a sysadmin to arbitrarily pick one, you got it. Since the editprotected solution (this bug) is cleaner and easier to implement than adding a new restriction type (bug 2433) I prefer this one and will close the other one as WONTFIX. -- 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 24496] UniversalEditButton
https://bugzilla.wikimedia.org/show_bug.cgi?id=24496 p858snake changed: What|Removed |Added CC||p858sn...@yahoo.com.au --- Comment #7 from p858snake 2010-07-23 09:05:58 UTC --- (In reply to comment #6) > Ups, most probably I mistyped the search query while looking for it in > DefaultSettings.php Since this is the case, I agree with you that asking for > it > during installation is not a good idea. Thank you for solving this! Can confirm its there, Line 3968. http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/DefaultSettings.php?view=markup#l3967 -- 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 24496] UniversalEditButton
https://bugzilla.wikimedia.org/show_bug.cgi?id=24496 mediaw...@kghoffmeyer.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from mediaw...@kghoffmeyer.de 2010-07-23 08:59:45 UTC --- Ups, most probably I mistyped the search query while looking for it in DefaultSettings.php Since this is the case, I agree with you that asking for it during installation is not a good idea. Thank you for solving this! (In reply to comment #5) > $wgUniversalEditButton is set to true in DefaultSettings.php, so its always > enabled unless the site admin explicitly disables it. Getting the installer to > ask about every single configuration variable seems like a bad idea, as there > are a lot, and many of them (like this one) 99% of people would not want to > 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 24505] Enable user group "editprotected" on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24505 p858snake changed: What|Removed |Added CC||p858sn...@yahoo.com.au Component|User interface |Site requests Version|1.16|unspecified Product|MediaWiki |Wikimedia --- Comment #3 from p858snake 2010-07-23 08:59:27 UTC --- Please stop creating bugs under the incorrect product/component combos, Site Requests go under "Wikimedia" then into the "Site Requests" component. -- 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 24505] Enable user group "editprotected" on hindi wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=24505 --- Comment #2 from mayurkumar 2010-07-23 08:54:30 UTC --- O.k Install Either Bug 24433 or this present Bug 24505. We leave it up to a sysadmin to arbitrarily decide which one to enable. We will be grateful to bugzilla to resolve this issue a soon as possible. Thank you With Regards Mayurkumar -- 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 24510] New: Reset the administrator password for unblock-zh
https://bugzilla.wikimedia.org/show_bug.cgi?id=24510 Summary: Reset the administrator password for unblock-zh Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: Mailing lists AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: xu.jimmy@gmail.com I was setting the moderator password yesterday. But for some unknown reason, now I can't log-in to the administrative interface (wrong password). I found nowhere to reset it by myself so I'm requesting the password to be reset. BTW, I can still moderate the list using the moderator password, so it's not too much urgent... Thanks. -- 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 24304] Reconfigure English Wikibooks
https://bugzilla.wikimedia.org/show_bug.cgi?id=24304 Nicholas Longo changed: What|Removed |Added CC||nmich...@gmail.com --- Comment #3 from Nicholas Longo 2010-07-23 08:28:36 UTC --- As the one opposing vote I fully concede there was a consensus, we have a small community, and it was a long debate with participation of many members. But I think these changes should be put through, despite my objections. Adrignola gives the link the the final support/opposing statements and they are a fair reflection of the community point of view. -- 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, optionally display iwprefix and iwtitle
https://bugzilla.wikimedia.org/show_bug.cgi?id=24485 Reedy changed: What|Removed |Added Summary|Make iwbacklinks a |Make iwbacklinks a |generator, display iwprefix |generator, optionally |and iwtitle optional|display iwprefix and ||iwtitle -- 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
