[Bug 25361] New: remove meta settings from CentralNotice config in svn
https://bugzilla.wikimedia.org/show_bug.cgi?id=25361 Summary: remove meta settings from CentralNotice config in svn Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralNotice AssignedTo: rkald...@wikimedia.org ReportedBy: rkald...@wikimedia.org Need to remove these from the default settings so that 3rd party mediawiki installs aren't pulling banners from meta. -- 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 17627] Allow autoconfirmed users to patrol on ar Wikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=17627 Ciphers changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #8 from Ciphers 2010-09-29 02:39:41 UTC --- The change is confirmed. Thank you! -- 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 23476] Add ability to test banners on demand for projects
https://bugzilla.wikimedia.org/show_bug.cgi?id=23476 Tomasz Finc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Tomasz Finc 2010-09-29 02:24:46 UTC --- Functionality has now been added, deployed, and documented. -- 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 25360] New: SpecialBannerLoader needs to append geo to request
https://bugzilla.wikimedia.org/show_bug.cgi?id=25360 Summary: SpecialBannerLoader needs to append geo to request Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralNotice AssignedTo: rkald...@wikimedia.org ReportedBy: tf...@wikimedia.org In order to gauge effectiveness of of banners we'll need to differentiate between banner views in languages that are spread out over multiple geographic areas like english, spanish, french, etc. It would be best if we were consistent with standards like ISO 3166-1. -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354
Leinad changed:
What|Removed |Added
CC||danny.lei...@gmail.com
--- Comment #15 from Leinad 2010-09-29 02:07:39 UTC ---
Hello!
I would like to report that Polish language also needs {{#switch: or some
substitute.
In Polish we have various grammar forms which depend on the name of the
project. If you do not fix this issue, we will have create not one, but six
banners for each project :(
--
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 25031] int messages are translated according to content language instead of user language in banners
https://bugzilla.wikimedia.org/show_bug.cgi?id=25031 Ryan Kaldari changed: What|Removed |Added Summary|int messages are not|int messages are translated |translated in banner|according to content |previews|language instead of user ||language in banners -- 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 25359] New: SpecialLoader sitename needs to not be localized for analytics
https://bugzilla.wikimedia.org/show_bug.cgi?id=25359 Summary: SpecialLoader sitename needs to not be localized for analytics Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralNotice AssignedTo: rkald...@wikimedia.org ReportedBy: tf...@wikimedia.org Right now the banner loader will send the following types of requests: GET http://meta.wikimedia.org/wiki/Special:BannerLoaderbanner=WMCZCeny01&userlang=cs&sitename=Wikipedie For consistent parsing we need sitename or another variable like it to correspond to the non localized project name or even better the db name. So instead of =Wikipedie we would get =cswiki -- 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 25031] int messages are not translated in banner previews
https://bugzilla.wikimedia.org/show_bug.cgi?id=25031
--- Comment #6 from Ryan Kaldari 2010-09-29 01:29:31
UTC ---
It looks like this is breaking {{int:...}} translation on the wikis as well
(see Bug 25358). As soon as r70517 and r72555 are deployed, this should be
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 25358] "Hide" button is localized according to content language, not user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=25358 Ryan Kaldari changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Ryan Kaldari 2010-09-29 01:26:56 UTC --- *** This bug has been marked as a duplicate of bug 25031 *** -- 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 25031] int messages are not translated in banner previews
https://bugzilla.wikimedia.org/show_bug.cgi?id=25031 Ryan Kaldari changed: What|Removed |Added CC||b...@caseybrown.org --- Comment #5 from Ryan Kaldari 2010-09-29 01:26:56 UTC --- *** Bug 25358 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 25358] New: "Hide" button is localized according to content language, not user language
https://bugzilla.wikimedia.org/show_bug.cgi?id=25358
Summary: "Hide" button is localized according to content
language, not user language
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: CentralNotice
AssignedTo: rkald...@wikimedia.org
ReportedBy: b...@caseybrown.org
The "Hide" button, and probably all messages included in the banners with
{{int:}}, currently shows in the content language, not the user language.
For examples, see the following links:
* content language en, user language en:
http://test.wikipedia.org/wiki/?uselang=en?banner=2010_testing42 (English
"Hide")
* content language en, user language de:
http://test.wikipedia.org/wiki/?uselang=de?banner=2010_testing42 (English
"Hide")
* content language en, user language de: http://en.wikipedia.org/wiki/?
banner=2010_testing39&userlang=de&sitename=Wikipedia (English "Hide")
* content language de, user language de:
http://de.wikipedia.org/wiki/?userlang=de&banner=2010_testing39 (German
"Ausblenden")
* content language de, user language en:
http://de.wikipedia.org/wiki/?userlang=en&banner=2010_testing39 (German
"Ausblenden")
--
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 20495] Support HTML5 data-* attributes
https://bugzilla.wikimedia.org/show_bug.cgi?id=20495 --- Comment #2 from Aryeh Gregor 2010-09-29 00:26:33 UTC --- Specifically, this was added in r70980. -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 --- Comment #14 from Ryan Kaldari 2010-09-29 00:25:20 UTC --- I think I have a solution that doesn't require guessing the database name or loading a remote wiki's configuration on every banner request. Stay tuned... -- 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 25357] New: Random giving articles with no article content
https://bugzilla.wikimedia.org/show_bug.cgi?id=25357
Summary: Random giving articles with no article content
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: Special pages
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: m8r-udf...@mailinator.com
On the english wiki, Special:Random gives articles whose content is {{wi}}
which means the article isn't on the english wiki, but on wiktionary...and
isn't really an article.
Is there a way to limit which articles get returned by Special:Random?
--
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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 --- Comment #13 from Ryan Kaldari 2010-09-29 00:15:04 UTC --- It looks like the old hack isn't easily implementable in the new system. Now that we are doing banner message localization based on user language rather than site language (which was another bug fixed by the new system) we can't use the site language for guessing the database name (an essential part of the hack) without further fragmenting our caching scheme. The hack also required doing $wgConf->loadFullData() on every banner request, which didn't matter when they were all pre-generated, but now that they are generated dynamically, that could be a performance hit. I'm still investigating solutions, however. -- 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 25257] specifying font size in pixels (px) or <1em diminishes usability
https://bugzilla.wikimedia.org/show_bug.cgi?id=25257 Platonides changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #3 from Platonides 2010-09-28 23:24:30 UTC --- Those 13x font-size contain: DON'T PANIC! Browsers that won't scale this properly are the same browsers that have JS issues that prevent this from ever being shown anyways. -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354
--- Comment #12 from Ryan Kaldari 2010-09-28 23:23:41
UTC ---
Yes, obviously it was needed, but it didn't say what it was needed for. I was
told it was needed for {{SITENAME}}. When I rewrote all of the banner loading
code (which was necessary in order to be able to support the new features
listed above), rather than reimplementing some kind of hack to allow partial
wiki parsing, I just wrote something very straightforward to support the output
of site names. I wasn't just throwing out old code for the fun of it.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 p858snake changed: What|Removed |Added CC||p858sn...@gmail.com --- Comment #11 from p858snake 2010-09-28 23:00:09 UTC --- (In reply to comment #10) > The original banner parsing code was prefixed with a warning declaring it "A > god-damned dirty hack" by whoever wrote it, so it wasn't actually my > subjective > opinion :) > > I agree that using parser functions for all the uses you describe probably > makes more sense than Javascript. I just wasn't aware those functions were > needed in CentralNotice banners. Not to be snarky, but if something is written in as a hack, it's generally needed (and wanted) even if people don't remember to tell you. -- 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 25356] New: using document.write() within a CentralNotice banner can cause a blank page
https://bugzilla.wikimedia.org/show_bug.cgi?id=25356 Summary: using document.write() within a CentralNotice banner can cause a blank page Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: minor Priority: Normal Component: CentralNotice AssignedTo: rkald...@wikimedia.org ReportedBy: rkald...@wikimedia.org Since the deploy of the new banner loading code, using document.write() within a CentralNotice banner can occasionally cause the page to be replaced with the contents of the document.write() function. This only happens every once in a while and thus is likely to be the result of some race condition in Javascript loading. Requires more investigation. -- 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 25350] Allow to search messages in Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25350 Krinkle changed: What|Removed |Added CC||krinklem...@gmail.com --- Comment #4 from Krinkle 2010-09-28 22:41:07 UTC --- It is already possible to filter by prefix. For text-search there is already a search function that goes through the MediaWiki-namespace. however that one only searches through modifiedmessages (ie. existing pages). So far my work around has been searching on translatewiki (as the pages do exist there). but this has the sideeffect that it often get's me only 1 result instead of 25 with 25 items per page (meaning, it gives me 25 languages of 1 item). So being able to search right in the core would really be a good improvement as this one allows picking a language. -- 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 25350] Allow to search messages in Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25350 Platonides changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | Summary|There are "more than all" |Allow to search messages in |messages in |Special:AllMessages |Special:AllMessages | --- Comment #3 from Platonides 2010-09-28 22:36:16 UTC --- We should however allow to search in the message contents, which is why the "All" option was added. Repurposing 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 --- Comment #10 from Ryan Kaldari 2010-09-28 21:31:03 UTC --- The original banner parsing code was prefixed with a warning declaring it "A god-damned dirty hack" by whoever wrote it, so it wasn't actually my subjective opinion :) I agree that using parser functions for all the uses you describe probably makes more sense than Javascript. I just wasn't aware those functions were needed in CentralNotice banners. Going on the information that I had (that we just needed a way to output the site name), I thought it made sense to throw out the parser hack (that was also causing problems with message caching) and just support $sitename as a sort of custom variable. Oh well, hindsight's 20/20. At least with the new banner loading system we can now do geotargeting, get real banner impressions, test banners within local wikis, and it doesn't break on secure servers. Trading 4 bugs for 1 isn't so bad is it? And thanks for the apology. It's frustrating to get criticism without elaboration or explanation. Constructive criticism is always welcome, however :) -- 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 25205] Automate generation of fundraiser tracking data, long term storage, and data mining
https://bugzilla.wikimedia.org/show_bug.cgi?id=25205 Tomasz Finc changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Tomasz Finc 2010-09-28 21:28:21 UTC --- The 2step proces is now well automated thanks to Nimish. Documentation to come next. -- 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 25288] Donate button not appearing on cc form in IE 8
https://bugzilla.wikimedia.org/show_bug.cgi?id=25288 Tomasz Finc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Tomasz Finc 2010-09-28 21:26:50 UTC --- Resolved in r73682 -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354
--- Comment #9 from MZMcBride 2010-09-28 21:10:29 UTC ---
(In reply to comment #8)
> So it's not reasonable to expect banner writers to know basic Javascript, but
> it is reasonable that they understand using Wikitext parser functions?
> Regardless, any way that this is implemented will be a hack since the banners
> don't live on the local wikis, they live on meta. So they can't just be parsed
> and pulled into the page like a template. And {{SITENAME}} is especially
> problematic for this reason. Obviously if I had known that this was needed, I
> would have built a better way to do it in CentralNotice. In the meantime, I'm
> offering a workaround. But next time, I'll just keep my "disgusting" ideas to
> myself :P
Sometimes, people look back at what was previously implemented and say "this
was a horrible hack, why did we do it this way?" I realize that some of these
problems aren't easy to solve and I realize the importance of this project. I
imagine that's why the Wikimedia Foundation has hired someone to work on this
rather than relying on volunteers. :-)
The problem with workarounds is that they have a tendency to become
long-lasting. This is true of a lot of areas of MediaWiki/Wikimedia
development.
In my view, there should be as little coding required by the users of this
extension as possible. While JavaScript is obviously more common on the Web,
for most wiki users, ParserFunctions/wikitext are more common and easier to
understand. This brings the benefit of people being available to help if the
ParserFunctions/wikitext get complicated. The same really isn't as true for
JavaScript, surprising as that may seem.
That said, I don't think supporting wikitext/ParserFunctions is necessarily a
must-have for this extension, but it does provide some somewhat sane features
(like {{PLURAL:}}) that could be handy in banners.
When non-coders (or even coders sometimes) are forced to do coding, especially
in an environment that doesn't have input sanity checks like Tidy, we end up
with all sorts of nastiness from things like unclosed tags, for example. Your
suggested code seems frail and hackish. I imagine you knew this when proposing
it. I didn't mean to judge you, just your suggestion, as being "disgusting."
I'm also a bit tired today; that's probably not helping matters either.
Apologies if I came across as snarky.
--
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 21295] Geolocation on CentralNotice
https://bugzilla.wikimedia.org/show_bug.cgi?id=21295 Ryan Kaldari changed: What|Removed |Added Status|NEW |RESOLVED CC||rkald...@wikimedia.org Resolution||FIXED --- Comment #4 from Ryan Kaldari 2010-09-28 21:08:59 UTC --- This was implemented as part of September 2010 CentralNotice phase II development. -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354
--- Comment #8 from Ryan Kaldari 2010-09-28 20:40:43
UTC ---
So it's not reasonable to expect banner writers to know basic Javascript, but
it is reasonable that they understand using Wikitext parser functions?
Regardless, any way that this is implemented will be a hack since the banners
don't live on the local wikis, they live on meta. So they can't just be parsed
and pulled into the page like a template. And {{SITENAME}} is especially
problematic for this reason. Obviously if I had known that this was needed, I
would have built a better way to do it in CentralNotice. In the meantime, I'm
offering a workaround. But next time, I'll just keep my "disgusting" ideas to
myself :P
--
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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 --- Comment #7 from MZMcBride 2010-09-28 20:29:00 UTC --- (In reply to comment #4) > Would you care to elaborate on the snarky comment? It's not snarky. I don't think it's particularly reasonable to require people implementing these banners to have a working knowledge of JavaScript. I think that requiring people to learn and use JavaScript is going to needlessly complicate these banners. Worse than requiring people to learn how to operate
[Bug 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 --- Comment #6 from Ryan Kaldari 2010-09-28 20:28:03 UTC --- The noscript is output if Javascript is turned off or isn't working. You'll still need to have a default option within the Javascript itself. If I can't figure out a good way to re-hack this functionality, I'll write up some complete Javascript for you to use for this situation. -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354 --- Comment #4 from Ryan Kaldari 2010-09-28 20:22:27 UTC --- Would you care to elaborate on the snarky comment? -- 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 25354] CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354
--- Comment #1 from Ryan Kaldari 2010-09-28 20:16:03
UTC ---
Most wikitext functions will not work in banners. The only reason some of them
worked before is because the banner pre-generation process allowed us to
implement some ugly hacks to use some of them. We should probably not be using
any wikitext within banners. We should be using HTML and Javascript instead. If
there is a requirement that banners use wikitext, we'll need to reimplement the
banner loader in a different way. When I asked Alex and Philippe about what
wiki functions were needed, I was only told about message translation and
{{SITENAME}}. No one mentioned the use of parser 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 24415] Resource loader (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=24415 Ryan Kaldari changed: What|Removed |Added CC||rkald...@wikimedia.org --- Comment #2 from Ryan Kaldari 2010-09-28 20:03:15 UTC --- Isn't this bug set up backwards? A tracking bug normally includes issues that need to be fixed in order to meet a certain milestone or release a certain feature. The bugs that will be fixed by that feature are then listed under "Blocks". Due to how this bug is defined, all the bugs that are blocked by Resource Loader are listed as "Depends on" and those bugs don't have a proper Resource Loader bug to list as a Blocker. Why don't we just have a bug called "Implement Resource Loader"? All the bugs that would be fixed by it can then be listed as "Blocks" and all the bugs that have to be fixed as part of the Resource Loader implementation would be listed as "Depends on". We don't need to reinvent this functionality by creating a "blocks tracker" (which inverts the normal dependency logic). It's too confusing, IMO. -- 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 24415] Resource loader (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=24415 Ryan Kaldari changed: What|Removed |Added Blocks|24862 | Depends on||24862 -- 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 24862] Wikipedia (Vector?) "doesn't work" in some installations of IEMobile
https://bugzilla.wikimedia.org/show_bug.cgi?id=24862 Ryan Kaldari changed: What|Removed |Added Blocks||24415 Depends on|24415 | --- Comment #6 from Ryan Kaldari 2010-09-28 19:49:34 UTC --- nevermind, that tracking bug is set-up backwards -- 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 23917] Commons favicon broken on Safari & Chrome (Mac) // Also distorted on other browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=23917 Casey Brown changed: What|Removed |Added Keywords|easy| CC||b...@caseybrown.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 25355] New: Parser generates edit section links for special pages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25355 Summary: Parser generates edit section links for special pages Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Page rendering AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: niklas.laxst...@gmail.com By default it shouldn't make edit section links in special pages. -- 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 25354] New: CentralNotice $sitename variable not working with ParserFunctions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25354
Summary: CentralNotice $sitename variable not working with
ParserFunctions
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: CentralNotice
AssignedTo: rkald...@wikimedia.org
ReportedBy: b...@caseybrown.org
CC: az1...@gmail.com, tf...@wikimedia.org
The new variable for {{SITENAME}} ($sitename) doesn't seem to be working with
ParserFunctions, which we need for some languages to work properly.
For example, see the Catalan version of the VectorNewLook_phase3 banner.[0] We
use this code:
{{#switch:{{SITENAME}}
|Viquipèdia=La {{SITENAME}} està
|Viccionari=El {{SITENAME}} està
|Viquillibres|Viquitexts=Els {{SITENAME}} estan
|Viquinotícies|Viquidites=Les {{SITENAME}} estan
|#default={{SITENAME}} està }} canviant d'aspecte.
so that the banner is grammatically correct on all of the projects.
I replaced {{SITENAME}} with $sitename to see if this still works with your new
variable, but it looks like it doesn't:
* http://ca.wikipedia.org/wiki/?banner=VectorNewLook_phase3
* http://ca.wiktionary.org/wiki/?banner=VectorNewLook_phase3
Both of those are showing the default phrasing, "SITENAME està", while they
should say "La Viquipèdia està" and "El Viccionari està" respectively... so
something's not working and the ParserFunction isn't being processed correctly.
[0]http://meta.wikimedia.org/wiki/Special:NoticeTemplate/view?template=VectorNewLook_phase3&wpUserLanguage=ca
--
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 25353] Url escapement in JSON
https://bugzilla.wikimedia.org/show_bug.cgi?id=25353
Roan Kattouw changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||roan.katt...@gmail.com
Resolution||WONTFIX
--- Comment #1 from Roan Kattouw 2010-09-28 19:27:25
UTC ---
PHP's json_encode() function does this, no idea why:
> echo json_encode(array('foo' => 'http://en.wikipedia.org/w/api.php'));
{"foo":"http:\/\/en.wikipedia.org\/w\/api.php"}
Marking WONTFIX cause we're using a library implementation that we can
reasonably expect not to be stupid (and that at least isn't generating invalid
JSON).
--
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 23917] Commons favicon broken on Safari & Chrome (Mac) // Also distorted on other browsers
https://bugzilla.wikimedia.org/show_bug.cgi?id=23917 DieBuche changed: What|Removed |Added Keywords||easy, patch, 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 25353] New: Url escapement in JSON
https://bugzilla.wikimedia.org/show_bug.cgi?id=25353 Summary: Url escapement in JSON Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: API AssignedTo: roan.katt...@gmail.com ReportedBy: diebu...@gmail.com CC: bryan.tongm...@gmail.com, s...@reedyboy.net, vasi...@gmail.com, soxre...@gmail.com Ok, maybe I'm missing some thing really obvious; but: Why are all / in URLs (for example the url given out by image info) escaped with a \ when format=json? / is no special character in JSON, the only one which needs escapement is " Sample Query: http://en.wikipedia.org/w/api.php?action=query&format=json&titles=Image:Test.jpg&prop=imageinfo&iiprop=url Result: [...] "url":"http:\/\/upload.wikimedia.org\/wikipedia\/en\/b\/bd\/Test.jpg" [...] -- 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 25352] New: Pipe (|) symbol breaks field definitions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25352
Summary: Pipe (|) symbol breaks field definitions
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: SemanticForms
AssignedTo: yaro...@gmail.com
ReportedBy: f.tr...@gmx.net
CC: wikibugs-l@lists.wikimedia.org
Using a pipe symbol in an "unexpected" place in a field definition (e.g. in a
parser function call) breaks the form.
E.g. for a form collecting geographic regions the following field definition
should just pass on the value for the parameter "structure" to the input type:
{{{field|Part of|input type=menuselect|structure= {{
#generateTree:property=Part of|display=Long name }} }}}
--
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 25283] Bug with centralnotice inclusion of secure server
https://bugzilla.wikimedia.org/show_bug.cgi?id=25283 Derk-Jan Hartman changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Derk-Jan Hartman 2010-09-28 18:48:27 UTC --- It seems the new code is live, and I no longer see this problem. -- 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 25346] Geo lookup causes mime type errors in Chrome
https://bugzilla.wikimedia.org/show_bug.cgi?id=25346 Derk-Jan Hartman changed: What|Removed |Added CC||hart...@videolan.org --- Comment #4 from Derk-Jan Hartman 2010-09-28 18:43:37 UTC --- ticket collision: It's not JSON though is it ? I mean it has "Geo =" that makes it JS, much like JSONP is just javascript. application/json should only be used icw. XMLHTTPRequest objects I think. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 24415] Resource loader (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=24415 Ryan Kaldari changed: What|Removed |Added Blocks||24862 Depends on|24862 | -- 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 24862] Wikipedia (Vector?) "doesn't work" in some installations of IEMobile
https://bugzilla.wikimedia.org/show_bug.cgi?id=24862 Ryan Kaldari changed: What|Removed |Added Blocks|24415 | Depends on||24415 --- Comment #5 from Ryan Kaldari 2010-09-28 18:35:06 UTC --- Changed Bug 24415 from a "Blocks" to a "Depends on" as I don't see how this bug could block the Resource Loader from being implemented. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25346] Geo lookup causes mime type errors in Chrome
https://bugzilla.wikimedia.org/show_bug.cgi?id=25346 --- Comment #3 from Ryan Kaldari 2010-09-28 18:32:28 UTC --- application/json is the correct MIME type for json (and indeed it seems that Chrome is the only browser complaining in this case). However, the geoIP JSON is not technically "well-formed" JSON, so this may be why Chrome is complaining. The geoIP JSON may not constitute "well-formed" Javascript either, so changing it to text/javascript may cause Safari to complain (as Safari seems to be sensitive to this). I guess what we need to do is test both MIME types in both browsers and see what we get. -- 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 25351] New: Log entries and edit summaries should be separate messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25351
Summary: Log entries and edit summaries should be separate
messages
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: Internationalization
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: theevilipaddr...@hotmail.de
Currently, messages like [[MediaWiki:Protectedarticle]] or
[[MediaWiki:Modifiedarticleprotection]] (also [[MediaWiki:Unprotectedarticle]],
[[MediaWiki:1movedto2]], [[MediaWiki:1movedto2 redir]] or
[[MediaWiki:Overwroteimage]] from which I remember in core, probably several
more in extensions) are used twice in the software: once as log entry, e.g.
Some guy (talk | contribs) protected "Foo" (Edit warring [edit=sysop]
(indefinite) [move=sysop] (indefinite)) or as summary in the revision history
and the protecting admin's contributions: protected "Foo" (Edit warring
[edit=sysop] (indefinite) [move=sysop] (indefinite))
However, I think that the edit summary should be different. It is a bit
pointless to repeat the {{FULLPAGENAME}} in the summary, because that's clear
already anyway if you look at some page's history or someone's contribs, where
the article is linked. Thus, it should rather be "protected page (Edit warring
[edit=sysop] (indefinite) [move=sysop] (indefinite)). Especially good would
such a change be when we have a long {{FULLPAGENAME}}. On Commons, where some
bots tend to make horribly long filenames, it already occured that when
uploading a new file version or protecting it, there was nothing but "uploaded
a new version of" or "protected" and some part of the {{FULLPAGENAME}} in it.
Furthermore (not in English probably) in some cases in German, different
sentences could be used depending on the situation, because one time the
shorter form is generally ok, but in the other case it would be wrong. This
would also some some characters in such a case. Also, would be a partial fix of
bug 16921.
I recognize that it may not be easy, I even personally looked where exactly
these messages are used within the software, looking if I can come up with some
ideas or even a patch, but I failed, so I wouldn't mind this lying around here
some time, since it appears not to be a simple fix.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 671] Whitelist non-problematic HTML tags: address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671 --- Comment #64 from The Evil IP address 2010-09-28 17:40:42 UTC --- I'd personally not whitelist the tag in core. Whereas it really may have some usage, i.e. on disclaimer pages or the like, I think it has far too few usages to be useful in the default configuration. Instead, I'd suggest coding a (probably simple) extension which allows the address tag in user input. This still allows you to use it if you really want, but prevents likely misuses when in the default installation. -- 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 20495] Support HTML5 data-* attributes
https://bugzilla.wikimedia.org/show_bug.cgi?id=20495 The Evil IP address changed: What|Removed |Added Status|NEW |RESOLVED CC||theevilipaddr...@hotmail.de Resolution||FIXED --- Comment #1 from The Evil IP address 2010-09-28 17:32:40 UTC --- This was added some time ago already and is available if $wgHtml5 is true, so marking as 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 25350] There are "more than all" messages in Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25350 --- Comment #2 from Helder 2010-09-28 17:09:29 UTC --- Fair enough ;-) -- 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 25298] Figure out what (if any) new Pending Changes links there should be in the side bar
https://bugzilla.wikimedia.org/show_bug.cgi?id=25298 Platonides changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #1 from Platonides 2010-09-28 17:04:32 UTC --- I don't think so. We don't have actions in the toolbox. I think that if added, It should go as a tab. -- 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 25298] Figure out what (if any) new Pending Changes links there should be in the side bar
https://bugzilla.wikimedia.org/show_bug.cgi?id=25298 Rob Lanphier changed: What|Removed |Added Summary|Figure out what (if any)|Figure out what (if any) |links there should be in|new Pending Changes links |the side bar|there should be in the side ||bar -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25296] History style cleanup - investigate possible fixes and detail the fixes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25296 --- Comment #2 from Rob Lanphier 2010-09-28 16:59:16 UTC --- This issue was the partially the result of the "ugly highlighting" comment in http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback/Archive_4#Succinct_yet_descriptive_list_of_issues_and_suggestions , as well as complaints from when Pending Changes was first launched. -- 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 25346] Geo lookup causes mime type errors in Chrome
https://bugzilla.wikimedia.org/show_bug.cgi?id=25346 --- Comment #2 from Tomasz Finc 2010-09-28 16:58:52 UTC --- What's interesting is the we changed it to application/json because that's what Safari was expecting. -- 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 25300] Better names for special pages in Pending Changes configuration
https://bugzilla.wikimedia.org/show_bug.cgi?id=25300 --- Comment #2 from Rob Lanphier 2010-09-28 16:51:10 UTC --- Also: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback/Archive_3#Naming_of_OldReviewedPages -- 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 25350] There are "more than all" messages in Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25350 Chad H. changed: What|Removed |Added Status|NEW |RESOLVED CC||innocentkil...@gmail.com Resolution||WONTFIX --- Comment #1 from Chad H. 2010-09-28 16:49:04 UTC --- n r64181, this was changed to say "5000" instead of "All" We don't actually want "All" here. We need limits :) 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 25350] New: There are "more than all" messages in Special:AllMessages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25350 Summary: There are "more than all" messages in Special:AllMessages Product: MediaWiki Version: unspecified Platform: All URL: http://en.wikipedia.org/w/index.php?limit=5000&title=S pecial:AllMessages&uselang=en OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: heldergeov...@gmail.com [[Special:AllMessages]] currently has a text "show [50] itens per page" by default (from [[MediaWiki:Table pager limit]], I think). If we change the number to [all], and click [Go], it just reloads the page with parameter "limit=5000", which nowadays is not large enough to show *all items* in one page (note: even after selecting *all* items the user still needs to go to a "Next page" to view more items...). Please fix two things: * Make the option "all" to show *all* messages, no matter how many messages there exist; * When this option is selected, the sentence "Show all items per page" should be just "Show all items", because there is only one page. Helder -- 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 25300] Better names for special pages in Pending Changes configuration
https://bugzilla.wikimedia.org/show_bug.cgi?id=25300 --- Comment #1 from Rob Lanphier 2010-09-28 16:42:16 UTC --- See http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback#Naming_of_special_pages for a discussion of the naming -- 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 24223] Add button to &diffonly=1 history link
https://bugzilla.wikimedia.org/show_bug.cgi?id=24223 Platonides changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #2 from Platonides 2010-09-28 16:09:44 UTC --- emijrp, you can change your preferences to have your diffs be diff only. -- 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 24223] Add button to &diffonly=1 history link
https://bugzilla.wikimedia.org/show_bug.cgi?id=24223 Rob Lanphier changed: What|Removed |Added CC||ro...@wikimedia.org --- Comment #1 from Rob Lanphier 2010-09-28 16:08:45 UTC --- We should be able to solve this in a more elegant way by using the approach described in bug 25289. Rather than adding more options in the UI, we can merely make the diff display before the old revision is done loading, and then load the old revision in due time. -- 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 3201] Provision of article skeleton
https://bugzilla.wikimedia.org/show_bug.cgi?id=3201 Chad H. changed: What|Removed |Added CC||ville...@iki.fi --- Comment #14 from Chad H. 2010-09-28 16:04:29 UTC --- *** Bug 25348 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 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 25348] Multiple new page layouts
https://bugzilla.wikimedia.org/show_bug.cgi?id=25348 Chad H. changed: What|Removed |Added Status|NEW |RESOLVED CC||innocentkil...@gmail.com Resolution||DUPLICATE --- Comment #1 from Chad H. 2010-09-28 16:04:29 UTC --- *** This bug has been marked as a duplicate of bug 3201 *** -- 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 25344] Closing category player during playback does not stop video
https://bugzilla.wikimedia.org/show_bug.cgi?id=25344 Michael Dale changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Michael Dale 2010-09-28 15:56:23 UTC --- fixed in r73914 -- 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 25289] Make review load faster by speeding up display of old revisions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25289 --- Comment #10 from Platonides 2010-09-28 15:04:25 UTC --- Note that just changing the diffonly=0 from the url of the Review link to diffonly=1 will give you a content-less diff. Adding a "show content" button to diffonly revisions should be easy, it's just fetching it from the api. -- 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 24894] CheckUser mass blocker unexpectedly blocks talk page access
https://bugzilla.wikimedia.org/show_bug.cgi?id=24894
--- Comment #2 from DF 2010-09-28 14:04:41 UTC ---
(In reply to comment #1)
> What options are wanted btw? I'm thinking three:
> *Block anonymous users only
> *Prevent account creation
> *Allow this user to edit own talk page while blocked
Sounds good. I would also add "prevent the user from sending email". I
understand that autoblock ("Automatically block the last IP address used by
this user, and any subsequent IP addresses they try to edit from") is set by
default when blocking accounts, right?
--
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 25318] Able to see other peoples messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25318 MZMcBride changed: What|Removed |Added CC||b...@mzmcbride.com --- Comment #2 from MZMcBride 2010-09-28 13:47:36 UTC --- If this confusing long-time users, it might indicate an underlying interface issue. There's probably a bug or two already filed about the interface being confusing, 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 25318] Able to see other peoples messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25318 Andrew Garrett changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Garrett 2010-09-28 13:35:02 UTC --- mysql> select wl_namespace,wl_title from watchlist join user on wl_user=user_id where user_name='Peachey88 (Public)' -> ; +--++ | wl_namespace | wl_title | +--++ |2 | Peachey88 | |2 | Peachey88_(Public) | |3 | Peachey88 | |3 | Peachey88_(Public) | +--++ 4 rows in set (0.00 sec) You're watching your other account's talkpage. -- 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 25304] Clean up tables post bug 25290
https://bugzilla.wikimedia.org/show_bug.cgi?id=25304 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED CC||roan.katt...@gmail.com Resolution||FIXED --- Comment #1 from Roan Kattouw 2010-09-28 13:25:59 UTC --- Done. Other than the two pages Gurch touched (which were pages where the rating widget isn't active anyway: his user page and the RfA page) there were no ratings > 5. -- 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 25305] Make an ultra-autoblock option
https://bugzilla.wikimedia.org/show_bug.cgi?id=25305 --- Comment #5 from Max Semenik 2010-09-28 13:22:38 UTC --- (In reply to comment #4) > Checkusers can tell what accounts shared same IP address, but can't tell > specific IP address they used. So we can't block IP address manually to stop > creating more accounts. That's why this function is suggested. From http://wikimediafoundation.org/wiki/Privacy_policy#Access_to_and_release_of_personally_identifiable_information : Where the user has been vandalizing articles or persistently behaving in a disruptive way, data may be released to a service provider, carrier, or other third-party entity to assist in the targeting of IP blocks, or to assist in the formulation of a complaint to relevant Internet Service Providers -- 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 25291] 100.9 MB DjVu upload on commons for fr.wikisource
https://bugzilla.wikimedia.org/show_bug.cgi?id=25291 Roan Kattouw changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Roan Kattouw 2010-09-28 13:17:50 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 25346] Geo lookup causes mime type errors in Chrome
https://bugzilla.wikimedia.org/show_bug.cgi?id=25346 Roan Kattouw changed: What|Removed |Added CC||m...@nedworks.org, ||roan.katt...@gmail.com --- Comment #1 from Roan Kattouw 2010-09-28 13:01:53 UTC --- CC Mark, who setup geoiplookup IIRC. The problem is that geoiplookup is returning a Content-Type: application/json header; this should be text/javascript . -- 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 25318] Able to see other peoples messages
https://bugzilla.wikimedia.org/show_bug.cgi?id=25318 Max Semenik 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 25349] New: Resource loader should allow loading messages in nonstandard ways (e.g. raw, forcontent, parsed, ...)
https://bugzilla.wikimedia.org/show_bug.cgi?id=25349 Summary: Resource loader should allow loading messages in nonstandard ways (e.g. raw, forcontent, parsed, ...) Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Resource Loader AssignedTo: roan.katt...@gmail.com ReportedBy: roan.katt...@gmail.com CC: roan.katt...@gmail.com Per summary. Came up at http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73811#c9621 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 671] Whitelist non-problematic HTML tags: address
https://bugzilla.wikimedia.org/show_bug.cgi?id=671 Chad H. changed: What|Removed |Added Summary|Whitelist non-problematic |Whitelist non-problematic |HTML tags: samp kbd address |HTML tags: address --- Comment #63 from Chad H. 2010-09-28 11:15:15 UTC --- Added samp and kbd in r73880. Removed from summary. -- 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 25029] PrefSwitch: Turning off the new features in all wikis fails
https://bugzilla.wikimedia.org/show_bug.cgi?id=25029 Krinkle changed: What|Removed |Added CC||krinklem...@gmail.com --- Comment #5 from Krinkle 2010-09-28 09:23:54 UTC --- Hm... I wish I didn't do the above Somehow it DID switch me on all wikis to Monobook (albeit it did show the previously reported error still). But... how do I switch back ? Will this become an option aswell (after this bug is 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 24894] CheckUser mass blocker unexpectedly blocks talk page access
https://bugzilla.wikimedia.org/show_bug.cgi?id=24894 --- Comment #1 from Aaron Schulz 2010-09-28 08:34:59 UTC --- What options are wanted btw? I'm thinking three: *Block anonymous users only *Prevent account creation *Allow this user to edit own talk page while blocked -- 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 24862] Wikipedia (Vector?) "doesn't work" in some installations of IEMobile
https://bugzilla.wikimedia.org/show_bug.cgi?id=24862 DieBuche changed: What|Removed |Added Blocks||24415 -- 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 24415] Resource loader (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=24415 DieBuche changed: What|Removed |Added Depends on||24862 -- 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 25348] New: Multiple new page layouts
https://bugzilla.wikimedia.org/show_bug.cgi?id=25348
Summary: Multiple new page layouts
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: Page editing
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: ville...@iki.fi
When starting a new article the wiki should ask the user what kind of an
article are they creating and load an appropriate layout. In essence my point
is that the MediaWiki:Newpagelayout serves nobody as most if not all wikis have
articles of several types.
Consider a wiki about a TV series. They have articles about seasons, episodes
and individual characters. That's at least three different layouts. New
contributors of the wiki cannot be of any help in creating new articles because
they don't know about the {{season}}, {{episode}} and {{character}} templates
used. At most they create an article stub which has to be completely rewritten
and templated by some experienced user. With multiple new page layouts they
would at least stand a chance on creating something useful when the layouts
would load the appropriate template and its parameters for them to fill.
My proposed solution is that in addition to the current MediaWiki:Newpagelayout
the pages MediaWiki:Newpagelayout# and MediaWiki:Newpagelayouttitle# are
deployed. Here, # would be a number from 1 to 9. When creating a new article
the wiki would ask: "What kind of an article are you creating?
{{:MediaWiki:Newpagelayouttitle1}}, {{:MediaWiki:Newpagelayouttitle2}}, None of
these?" The texts would be links which would deploy the associated
MediaWiki:Newpagelayout# as the basis for the new article. The last link, "None
of the above", would of course use the current default MediaWiki:Newpagelayout.
All those links would be loaded only if those special articles existed. If only
the regular Newpagelayout existed then there would be nothing to prompt and
that layout should be loaded without questions.
--
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
