At 23:25 13/03/2007, you wrote:
>2007/3/13, Ian Tresman <it(a)knowledge.co.uk>:
>
> > If their User IP was identified with, for example, a college, then
> > several people could indeed be using the same Wikipedia User IP address.
> >
> > But if their IP address is identified with a private residential
> > broadband account, then the only ways it could be compromised is:
> >
> > a. Someone else has access to the same computer
> > b. The home computer has a Trojan giving access to an intruder
> >
>
>c. They have an unprotected wireless network
>
>And of course there is also the possibility that their IP is neither college
>nor private but (for example) an ISP-based cache.
1. That would imply it's shared... and there would probably be a
record of it during a Google search?
2. And if I ping the IP address, it should be active 24-hours a day,
nor when the customer is out at work?
Regards,
Ian
>--
>Andre Engels, andreengels(a)gmail.com
>ICQ: 6260644 -- Skype: a_engels
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l(a)lists.wikimedia.org
>http://lists.wikimedia.org/mailman/listinfo/wikitech-l
First some background, why do we use compressed audio:
1) Uncompressed audio is huge and uses a lot of disk space for us.
2) Uncompressed audio would be an amazing waste of our bandwidth.
3) Uncompressed audio would be a huge burden on our readers, and would
make clips longer than a few seconds inaccessible to users on dialup.
Brion may stab me for saying it, but (1) is fairly unimportant.
The way we are using compressed audio today is not very good from the
perspective of (2), and (3).
I haven't gone and exhaustively checked our files, but most of the
Ogg/Vorbis files I'm seeing people upload are in the 160kbit/sec
range. I believe there are four reasons for this:
1) An incorrect impression created by old data about MP3 performance.
Old MP3 wisdom is that you have to be 160kbit/sec to be good. This was
true five years ago.
All cutting edge perceptual coders have results which are very good at
128kbit/sec, Vorbis better than the others, with results which are
nearly statistically the same as the original on a test using trained
listners.(http://www.listening-tests.info/mf-128-1/results.htm)
2) My recording is a unique and precious snowflake. I want it to be
the highest quality.
3) You can go down but you can't go up, and I have broadband so it's
fast enough for me.
4) Lossless files are bad for editing, less loss is better.
Of these, *none* of them should be a factor is deciding what we send
to our readers. Yet here we are sending these 160kbit/sec oggs to
joe-average-reader, sucking up his bandwidth and ours.
In terms of what we need uploaded for our own purposes, (4) matters.
It matters a lot, because being able to edit the content is an
important part of what we enable. However, even the 160kbit/sec lossy
files fail here: Take a file decoded from a 160kbit/ogg and pass it
through a 1500Hz high pass filter ('sox input.wav output.wav highp
1500' for those with real computers (tm)). The result will have
obvious yucky artifacts. This isn't a bug, it's the behavior of a
perceptual codec by design. The high pass trick is a pathological
worst case, but it is true that even at 160kbit/sec perceptual codecs
do not survive all forms of manipulation well.
What I'd like to see us do instead, is to ask uploaders to send us
losslessly compressed Ogg/Flac files instead. Lossless compression
because disk space isn't totally irrelevant and to avoid people
downloading insanely huge wavs just because they don't want to use the
java player or install a codec. We already permit uploading these
lossless audio files they can be easily transcoded to Ogg/Vorbis while
preserving all metadata.
Then we would, either via an automatic transcoding bot or via an
upload enhancement to mediawiki automatically generate 40kbit/sec
(dialup) and 96kbit/sec (broadband) versions from the lossless. These
versions are what we'd link from our other projects.
Considering the quality of most audio/video sharing sites on the
internet, these would still leave us head and shoulders better
quality. (Most youtube videos seem to be using 8 or 16kbit/sec mp3 for
their audio, it's miserable but you don't notice if you're watching
the video)
Thoughts on this? On using a bot vs some native support? The biggest
limit I see on this is that we don't have any support for subfiles, or
bundled files... which means that this gunks up commons with two extra
files for our audio.
Hi christoph huesler,
Thanks for your response.
When i click xyz, a template should be created where user can enter any
details(say schedule)
when i click abc, a different template should be created where user can enter
some other details(say news)
This should be done using mediawiki.
No as you said i will create one page called Template:<xyz>
and another page called Template:<abc>
Should i do this in function performAction in wiki.php using switch case 'raw'
or is it something else?
When i click xyz, a template should be created where user can enter any
details(say schedule)
when i click abc, a different template should be created where user can enter
some other details(say news)
This should be done using mediawiki.
I will create one page called Template:<xyz>
and another page called Template:<abc>
Should i do this in function performAction in wiki.php using switch case 'raw'
or is it something else?
I'm currently searching for an extension which allows the TOC to be
extracted from the page and used elsewhere in the skin (for example,
in a sidebar - outside the confines of the article itself). It seems
to be a common request yet I haven't been able to find any solutions.
If this extension does not exist then I will be making one. It's my
first time delving in to Mediawiki so I would appreciate any guidance
on how to go about doing this.
I've found this post which seems to be an overview of what I need to
do - can anyone expand on this?
http://article.gmane.org/
gmane.science.linguistics.wikipedia.technical/17938/
Best Regards,
Chris
(sorry for the double post)
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r20381).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter) [Has never passed]
* URL-encoding in URL functions (multiple parameters) [Has never passed]
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html) [Has never passed]
* TODO: Link containing double-single-quotes '' (bug 4598) [Has never passed]
* TODO: message transform: <noinclude> in transcluded template (bug 4926) [Has never passed]
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926) [Has never passed]
* BUG 1887, part 2: A <math> with a thumbnail- math enabled [Has never passed]
* TODO: HTML bullet list, unclosed tags (bug 5497) [Has never passed]
* TODO: HTML ordered list, unclosed tags (bug 5497) [Has never passed]
* TODO: HTML nested bullet list, open tags (bug 5497) [Has never passed]
* TODO: HTML nested ordered list, open tags (bug 5497) [Has never passed]
* TODO: Inline HTML vs wiki block nesting [Has never passed]
* TODO: Mixing markup for italics and bold [Has never passed]
* TODO: 5 quotes, code coverage +1 line [Has never passed]
* TODO: dt/dd/dl test [Has never passed]
* TODO: Images with the "|" character in the comment [Has never passed]
* TODO: Parents of subpages, two levels up, without trailing slash or name. [Has never passed]
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes. [Has never passed]
Passed 493 of 511 tests (96.48%)... 18 tests failed!
Already exists. Go to ?action=history and look at the sidebar. :)
On 12/03/07, Titoxd at Wikimedia
<http://lists.wikimedia.org/mailman/listinfo/wikitech-l> <titoxd.wikimedia
at gmail.com <http://lists.wikimedia.org/mailman/listinfo/wikitech-l> >
wrote:
> Some pseudocode (someone who knows what they are doing should probably fix
> it :P):
Not on watchlists, but on pages - would something that would give an
RSS feed of the history if you added "?action=rss" cause the servers
to melt? Shirley not (cross fingers).
- d.
On 3/9/07, raymond(a)svn.wikimedia.org <raymond(a)svn.wikimedia.org> wrote:
> Revision: 20304
> Author: raymond
> Date: 2007-03-09 15:08:56 -0800 (Fri, 09 Mar 2007)
>
> Log Message:
> -----------
> * (bug 5619) Split statistics messages for brighter output if
> $wgDisableCounters or $wgMiserMode are true
Don't you think it would be a good idea to figure out some way to
*not* throw away the sitestatstext messages for every single language
other than German or English? And is there any reason to break
backwards compatibility for userstats-text (as well as, again, the
slight issue of most of our supported languages reverting to the
English messages since you didn't change the names in all those
files), other than wanting to be tidy?