> Earlier: "... Or http://www.mediawiki.org/wiki/Mailing_lists which is
a little more focused on the software (rather than WMF sites that use
it) ..."
Excellent example of accuracy and brevity, what should probably have
been the first reference in this many contributor, long and cross-posted
thread. I am guilty of overkill in my attempt to figure it out. Please
forgive me.
EXIF is not IPTC metadata - see http://www.exif.org/ versus
http://www.iptc.org/photometadata/ and so on.
Let's open a can of worms!
No ... let's write an extension to, or core for, MediaWiki that only
permits successful image upload when all metadata is filled in on a
web-form during submission, and that form's blanks get:
(a) automatically read from metadata within images that already have it
at the time of upload; and / or
(b) gets that metadata inserted by the end user / submitter for any data
that is missing; and
(c) contemporaneous data gets inserted, such as IP and date and user ID.
I have my camera automatically put "peterblaise.com" in the EXIF of my
images immediately during the making of even the latent image (that's
when my copyright happens), but many image converters strip out EXIF and
IPTC metadata. Many people superimpose their copyright IN the image
fascia, but cropping or cloning can remove that, and too overwhelming a
copyright notice changes the image and often makes it purposeless.
Rather than contact you with a credit card (are you even ready?) for a
non-watermarked copy, and await your response, they will move on to a
non-watermarked image.
The world's most popular free Google Picasa strips metadata at the time
of export and replaces it with "Picasa" in the "Byline:"!
That newspaper should never have published that image without having,
and being able to provide on demand, an audit trail of it's origins. If
Joe Reader sent it in, then the newspaper should have that audit trail,
and then Joe Reader is the one to sue (civil) for compensation, and also
complain to the authorities (criminal) for prosecution. If the
newspaper uses Picasa and just publishes anything it wants, it should be
confronted on both civil and criminal counts.
Back at ya:
Q: How can any of us prove the picture was ours before someone else
publishes it?
A: http://www.copyright.gov/register/visual.html
--
Q: How to insert IPTC metadata in our image files before distribution?
A: http://www.photools.com/ and hundreds of other controlled vocabulary
IPTC-compatible software - see also http://www.controlledvocabulary.com/
--
So, cc: wikitech-l(a)lists.wikimedia.org is anyone up for developing an
extension or core code to make MediaWiki accurately handle such MEDIA as
photography and images with EXIT and IPTC metadata? Sound recordings
can't be far behind. Spoken work and music are ripe for cataloging
wiki-style. Will it be MEDIAWiki style?
cc: also to
http://picasa.google.com/support/bin/request.py?contact_type=testimonial
On Dec 6, 2007 11:34 AM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:
> On 06/12/2007, Brion Vibber <brion(a)wikimedia.org> wrote:
> > Thomas Dalton wrote:
> > >> Doesn't MediaWiki allow access control per namespace?
> > >
> > > By default, no.
> >
> > Actually, yes. I don't know how much I'd trust it for limited *read*
> > access, but it probably works. Mostly. :)
>
> Really? How? The only per namespace restrictions I know of is
> $wgNamespaceProtection or whatever it's called, but AFAIK, that just
> stops editing, not reading.
>
http://www.mediawiki.org/wiki/Manual:%24wgNonincludableNamespaces is
also in the main code, but that doesn't directly limit read access.
http://www.mediawiki.org/wiki/Extension:Hidden_pages is something else
to look at.
But neither is a complete answer to your question. Brion, are you
talking about an extension, or main code feature?
Yuri Astrakhan schreef:
> Congrats :)
>
Thanks. It took some 5 months to get the whole thing done, and I'm glad
it's more or less finished now. When I have more time (in a few weeks)
I'll look into the apiedit_vodafone branch, which has been inactive for
quite a while if memory serves.
BTW, the apiedit branch has actually been deleted now, in r28187.
Roan Kattouw (Catrope)
Gentlemen, config/index.php has called interwiki.sql and produced
table wiki_interwiki as expected. OK, but why won't e.g.,
[[commons:Bla]] become a blue interwiki link instead of a red local
link? Yes I read http://www.mediawiki.org/wiki/Help:Interwiki_linking
but feel that as I find the table already exists, I should not need to
do anything more.
> I stand corrected. Having now actually downloaded one of the dumps, I
> see it only contains the username of the most recent contributor to an
> article, not previous contributors. That's not good... shouldn't be
> too hard to fix, though - I'll take a look at the relevant code.
Odd... the code to include a list of authors is already there, it's
just not being used. The variable that determines whether or not to
include the list is just set to false, rather than being taken as a
parameter. I'm sending this email to wikitech-l as well, hopefully
someone there can explain why...
> Earlier: "... And your point is ? ..."
Peter Blaise responds: How much energy do you have for this?
We were discussing parser behavior, then 2 people suggested the chat should be on another list, yet they did not provide a link. I quoted a link, and the (apparently) initial reference to the list. Is there more? Maybe we should occasionally revisit the list of lists, and quote it here, as of today:
http://meta.wikimedia.org/wiki/Mailing_lists/overview
Wikimedia Foundation:
foundation-l (archive) - mailing list for the Wikimedia Foundation
wikitech-l (archive) - software development and Wikimedia maintenance
wikitext-l (archive) - markup and parsers discussions
mediawiki-api (archive) - announcement & discussion list for MediaWiki API
mediawiki-l (archive) - announcement & help list for people using the software to run other wikis
mediawiki-i18n (archive) - MediaWiki internationalisation and language setup
mediawiki-announce (archive) - update and security announcements only (low-traffic)
mediawiki-cvs (archive) - automated notifications of Subversion commits
wikibugs-l - automated notifications of bug reports
wikibots-l (archive) - discussion list for bot-editor users on Wikimedia sites
wiki-research-l (archive) - low volume list for people who are actively engaged in research on the Wikipedia project
wiki-offline-reader-l (archive) - list for the co-ordination of work on a free offline MediaWiki reader
translators-l (archive) - a list for discussing and announcing translations across the Wikimedia projects
wikimania-l (archive) for announcements and discussion about the Wikimania conference
wikiquality-l (archive) discussions regarding the design and implementation of quality-related technology for Wikimedia projects, as well as quality policies and initiatives.
oversight-l - Private mailing list for Oversight users.
stewards-l - Private mailing list for Stewards.
checkuser-l - Private mailing list for CheckUser users.
Wikimedia chapters:
WikimediaAU-l (archive) - for matters relating to the planned Australian chapter, but not concerning the wider Foundation
Wikimedia-ca (archive) - for matters relating to the planned Canadian chapter, but not concerning the wider Foundation
WikimediaCH-l (archive) for matters relating to the Swiss chapter, but not concerning the wider Foundation.
VereinAT-l (archive) - for matters relating to the planned Austrian chapter, but not concerning the wider Foundation
VereinDE-l (archive) - for matters relating to the German chapter, but not concerning the wider Foundation
WikimediaFR-l (archive) - for matters relating to the French chapter, but not concerning the wider Foundation
WikimediaNL-l (archive) - for matters relating to the Dutch chapter, but not concerning the wider Foundation
WikimediaPL-l (archive) - for matters relating to the Polish chapter, but not concerning the wider Foundation
WikimediaRO-l (archive) - for matters relating to the proposed Romanian chapter, but not concerning the wider Foundation
WikimediaSR-l (archive) - for matters relating to the Serbian chapter, but not concerning the wider Foundation
WikimediaUK-l (archive) - for matters relating to the UK chapter, but not concerning the wider Foundation
Project mailing lists:
wikipedia-l (archive) - for global issues, relating to all language versions of Wikipedia (see below for local mailing lists)
wikisource-l (archive) - for global issues, relating to all language versions of Wikisource
textbook-l (archive) - for global issues, relating to all language versions of Wikibooks (see below for local mailing lists)
wiktionary-l (archive) - for global issues, relating to all language versions of Wiktionary (see below for local mailing lists)
wikinews-l (archive) - for global issues, relating to all language versions of Wikinews (see below for local mailing lists)
wikiversity-l (archive) - for global issues, relating to all language versions of Wikiversity
wikispecies-l (archive) - for global issues, relating to all language versions of Wikispecies
commons-l (archive) - for the Wikimedia Commons-related discussion
wikiquote-l (archive) - for Wikiquote-related discussion
Wikimediameta-l - list for issues specific for the Meta-Wiki (the wiki where you are now)
Local Wikipedia mailing lists:
wikials-l (Alemannisch)
wikiar-l (العربية)
wikica-l (Català)
wikida-l (Dansk)
wikide-l (Deutsch)
wikien-l (English)
daily-article-l (archive) - sends the current article featured on the Main Page to all subscribers
wikieo-l (Esperanto)
wikies-l (Español)
wikifi-l (Suomi)
wikifr-l (francophone)
wikihi-l (हिन्दी)
wikihu-l (Magyar)
wikiia-l (Interlingua)
wikiis-l (Íslensk)
wikiit-l (Italiano)
wikija-l (日本語)
wikimk-l (Македонски)
wikinl-l (Nederlands)
wikino-l (Norsk)
wikipl-l (Polski)
wikipt (Português)
wikiru-l (Русский)
wikisa-l (Sanskrit)
wikiskan-l (new all-Scandinavian list)
wikisv-l (Svensk)
wikita-l (Tamil)
wikite-l (Telugu)
wikivi-l (Tiếng Việt)
wikizh-l (中文)
Local Wiktionary mailing lists:
WiktionaryDE-l (Deutsch)
WiktionaryPT-l (Português)
Local Wikibooks mailing lists
WikibooksDE-l (Deutsch)
Local Wikinews mailing lists
Wikinews-DE-l (archive)
Related mailing lists:
Pywikipedia-l - for discussion about the python mediawiki bot framework
toolserver-l - for announcements and discussion about and regarding the toolserver
Defunct:
intlwiki-l (archive) - formerly for Wikipedia internationalisation and multilingual coordination, closed in favor of wikipedia-l (for project-wide issues), wikitech-l (for tech issues) and requests for permissions (for administrative setup on small wikis)
wikilegal-l (archive) - legal & licensing issues, deprecated by foundation-l and the individual project mailing lists
See also:
There are other ways of communicating with the community besides mailing lists. Some of them include:
Wikimedia Meta-Wiki – a general discussion and brainstorming wiki
Wikimedia IRC channels – live chat
Village pump equivalents on different projects – for discussions relating to the specific project
==
Retrieved from "http://meta.wikimedia.org/wiki/Mailing_lists/overview" (with clickable links), but at least this list will be fresh in our archives for anyone who searches.
> Earlier: "... Whether or not you think it's
> a waste of time, there's no excuse for
> broadcasting every parser bug you find
> to three mailing lists. There's no
> shortage of parser bugs, and no need
> to act surprised when you find one ...
> If we want to talk about the parser
> grammar effort, we all know which list
> to subscribe to ...
Peter Blaise responds: Oh? Which one? I do not know, and you do not
mention it in your post, so, help me out here, please - which list? If
you're gonna type something, why not make it unambiguously accurate and
complete, anyway? Otherwise, what's the point?
Additionally, I personally find cross posting very important. Of course
anyone NOT interested can just scroll on or delete - there's no such
thing as too much information in my book (on topic - I'm not talking
about spam or off topic posts). Parser behavior = wiki tech in my book.
I very often I find spirited discussions ensue because of cross-posted
ideas - it tends to freshen otherwise stale meeting places.
More to the point here, wiki markup parser wise, my point is twofold:
One, I would prefer NOT to have my wiki end users get error messages
when they edit. I'd prefer that any editing just go in and be saved,
and later we'll deal with formatting surprises. I'm a firm believer in
separating the tasks of content creation and content presentation.
Someone adding content to a wiki should never be delayed by presentation
formatting error messages. Let the text land however it lands, clean it
up later.
Two, we tend to discover how things work in spite of erroneous,
presumptive, naive instructions. I already have begun to discard the
"rule" that bold happened between three apostrophes. Instead, I've
discovered a hierarchy of toggles. Three apostrophes toggle bold to the
other state. Two apostrophes toggle italics to the other state. The
parser makes it decisions on how to interpret duplicate punctuation at
the END of any code that matches it's look-up-table, or at the first
"word barrier" transition. Or does it? Cut and paste this into any
sandbox page and explore:
'1text = apostrophe one text; no duplicate punctuation, no wiki markup.
''2text = italics two text; duplicate punctuation matched wiki markup,
and the parser toggles the state of the matching function, here,
italics.
'''3text = bold three text; duplicate punctuation matched wiki markup,
and the parser toggles the state of the matching function, here, bold.
''''4text = bold apostrophe four text; duplicate punctuation matched
wiki markup, and the parser toggles the state of the matching function,
here, bold (3 apostrophes) was the superior interpretable state before
the 4th apostrophe, so bold toggles (on or off), and the final
apostrophe is interpreted as mere punctuation or text. Alternatively,
four apostrophes could be considered as two toggles of the italics
function. But, since the first word barrier occurs only after the 4th
apostrophe, and there is no text between the apostrophes, that
interpretation would not have any visible effect on the display. It
probably makes sense to have the parser continue interpreting up to the
third apostrophe before making a decision, and consider it a call for a
bold-toggle, rather than consider the first two apostrophes as an
italics-toggle, and then start looking for a subsequent wiki markup
instruction. Otherwise, the parser would never find bold (3
apostrophes) if it always gave precedent to interpreting the first 2
apostrophes as italics. The parser seems to reads left to right, and
interprets according to (what we hope are ) discoverable hierarchies:
word transitions, or, matching duplicate punctuation to wiki markup
code, whichever it finds first, such as knowing that three apostrophes
toggles bold.
'''''5text = italics bold five text; which toggled first? Who knows? I
presume bold toggles first, then italics toggled. Let's test:
'''bold '''''5text = italics five text (no bold); implying the five
apostrophes were interpreted bold as highest in the hierarchy, so, of
the five apostrophes, the first three were considered a bold-toggle, and
final two were considered an italics-toggle.
''italics '''''5text = bold five text (no italics); implying bold again
wins, and the subsequent italics-toggle turns off italics as expected,
the pattern is, so far, predictable. But let's revisit four
apostrophes:
'''bold ''''4text = bold apostrophe normal four text, this makes no
sense. In the four apostrophe grouping, the first three should have
toggled bold, and the final should have been interpreted as text,
displaying '4text normal, but when actually displayed, the ' was bold
and the 4text was normal. Huh? THERE'S THE BUG!
''italics ''''4text = normal two apostrophe four text, again, in the
four apostrophe group, the first three should have been a bold toggle
and the subsequent apostrophe should have been text. Apparently the
parser holds the existing state of wiki markup toggle in it's head and
raises that in the hierarchy. Who does this programming, anyway? Let's
test italics on and off first, not just on first:
''real italics'' ''''4text = normal apostrophe, bold four text. This
SHOULD be the same as avobe, but isn't. Apparently we need to add one
more item to our expected parser function hierarchy, THIS IS WHAT THE
PARSER SEEMS TO ASK:
1 - is there a bold or italics toggle ON outstanding? (This surprised
me, I thought toggles ON and OFF were hierarchically equivalent, but
apparently a toggle ON creates a pressing need to look for a toggle OFF
before interpreting anything else!)
Then:
2 - have we reached the superior matching wiki markup text? (On other
words, ''' is superior to '' in the look-up-table.)
3 - have we reached a text word barrier or paragraph barrier?
(Supposedly, paragraph markers reset all toggles to OFF, but apparently
some wiki markup survives paragraph markers, or is it only HTML-style
markup using <markup></markup>-style coding that ignores paragraph
markers?)
Continuing the test:
''''''6text = italics bold apostrophe six text
'''''''7text = italics bold 2 apostrophe seven text
''''''''8text = italics bold 3 apostrophe eight text
... and so on.
>Earlier: "... parser bugs, and ... parser grammar ..."
> see
http://lists.wikimedia.org/pipermail/wikitech-l/2007-November/035050.htm
l
... which say:
[Wikitech-l] [ANNOUNCEMENT] New mailing list for wikitext and parser
discussions
Domas Mituzas midom.lists at gmail.com
Fri Nov 16 10:01:21 UTC 2007
Hi!
We created new mailing list wikitext-l at wikimedia.org, <<
http://lists.wikimedia.org/mailman/listinfo/wikitech-l>> and for now
assigned Steve Bennett to handle the administrative part of that.
Please move wikitext and parser related discussions there, as
they
lately became off-topic.
This list would better see actual working (and better/faster)
realizations of parsers, instead of theoretical discussions on
something nobody is working on anyway.
Best regards,
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
==
nc