> Earlier question: "...what's the problem
> you see in IPE In Place Editing /
> WYSIWYG What You See Is What You Get?..."
> Earlier Answer: "... Loss of templates
> and CSS. ... Do we really want every
> wiki page to look different [Sure,
> template overload has caused some
> of that but generally not within a
> single wiki.]? Hardly any "regular"
> user of Word uses styles and rarely do
> "regular" web page authors use CSS.
> All of the styling is done inline. Ugh.
> THAT's the problem with WYSIWYG. I
> will agree that asking these people to
> learn wiki-text is asking a bit much -
> especially with complex inclusion
> templates, but I would MUCH rather
> have an extension that presents a
> form based on a template that allows
> users easier manipulation of data in
> the wiki than to go straight
> WYSIWYG or IPE..."
Peter Blaise responds: Fascinating - a third alternative, SI Structured
Input. Now, we have:
UI / RTACE - Unformatted Input / Raw Text And Code Editing
Alternatives being proposed:
WYSIWYG - What You See Is What You Get
IPE - In Place Editing, including WYSIWYG by default
PS/FBI - Pre Structured / Form Based Input (IS - Structured Input)
My challenge to PS/FBI - Pre Structured / Form Based Input is the PRE
part of it - all future, subsequent input must be PRE-thought of by
someone else, first. So, if I want to do something new, what do I do,
apply for a new permit from the programmers so they can build a
pre-structured input form for my nascent idea?
We're not doing data entry in a checking account register. We're trying
to build an inclusive community, seeking contribution of, and a
repository for, the world's knowledge, freely shared - and that means
massive amounts of unprecedented INPUT, as well as OUTPUT.
As it is now, OUTPUT is freely shared, but the complexities of Wikipedia
INPUT is still a barrier for many sources of human knowledge to overcome
and contribute.
"Images" are one example of INPUT barriers.
"Categorizing" is an intermediate problem within Wikipedia once anything
has been entered or uploaded, where data already input is hardly
findable due to lack of expansive human categorization, especially
images missing EXIF and IPTC metadata. Here's the place for a Pre
Structured / Form Based Input scheme to catalog images - the Commons:
http://commons.wikimedia.org/
Let's compare current Commons data collection:
http://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ow
nwork
{{Information
|Description=
|Source=self-made
|Date=
|Author=
|Permission=
|other_versions=
}}
With IPTC voluminous data collection:
Text fields in the current specification include but are not limited to
Caption,
Caption Writer,
Headline,
Special Instructions,
Keywords,
Category,
Supplemental Categories,
Urgency,
Byline,
Byline Title,
Credit,
Source,
Object Name,
Date Created,
City,
Province-State,
Country Name,
Original Transmission Reference,
Preserve Additional Information.
Additional fields beyond the IPTC specification:
Mark As Copyrighted
URL
And don't get me started on EXIF metadata and Maker Notes.
Also note that GPS data is starting to proliferate.
Are we doing anything with this data, intelligently, automatically?
This is where PS/FBI Pre Structured / Form Based Input can really play
an important role - helping us input and categorize data so it can be
found!
Hi, all:
I have a question about the browsing. Now in Dspace we can browse by
Titles, Authors, Subjects, and Dates. Now I want to add another field,
for example, "By Media". But I try several times, this function does
not work. Does anyone have some suggestions?
Thanks,
hong
> Earlier: "... I have NO INTEREST in
> users being able to edit "in place" on
> the same page ... at the very
> LEAST the user should be doing so on
> a page which is separate from the
> presented html, such as through
> the present use of the Edit link..."
Peter Blaise responds: ... because?
Now, I can see doing something on screen to remind the visitor they have
changed modes. An [Editing] watermark? But, why reformat the exact
thing they are looking at, the exact thing they want to edit, and make
them go to a new layout to re-find it all over again? I think the
current system keeps contributions lower than could be. That's probably
acceptable from a support point of view. However, I think it limits
contributions to a sub-set of all visitors, limits editing to
technically savvy and patient people, and that limits Wikipedia, that
limits ANY wiki.
The reason I suggest IPE In Place Editing is because that's what I see
the end users try to do first when told that they can "edit every page".
They see a blinking cursor in the text exactly where they want to make a
change, and so, they immediately start typing, right there on the page,
where they want to.
They know they can highlight text in a web page, just like in a text
editor, so there's no immediate feedback that they can't also edit every
page that way.
They know they can cut and paste text OUT of their browser into another
program, just like a text editor when they see the exact same blinking
cursor.
They know that it's really editable text underneath it all anyway,
somehow.
So they just point, click to get a familiar blinking cursor, and of
course they then want to immediately start editing. And they do. They
actually start typing, right there on any web page - cool!
"Nooooo!", I have to say, "You have to scroll and click the [edit] link
first ... then wait for a new window to open ... then scroll to a new
edit frame in that new window ... then click inside that edit frame ...
then scroll within the differently formatted copy of the original text
you saw only moments ago to re-find the exact text (now in a different
font, by the way) that you were just trying to edit ... then you can
type your desired changes ... you do remember what you wanted to say,
don't you?"
"Oh?" the potential wiki user asks. "Is there more?"
Could there possibly be more?
"Oh, yes," I say, "Then you have to save, of course, as with any data
entry ... but ... remember to put in a summary to be courteous to the
next viewers of the page history (what's that?) ... also select minor
edit or not (what's that?) ... and you might want to preview a few times
while you edit to make sure it's gonna look the way you want ... and you
might want to download the Google toolbar first so you can spell check
(at least the first 100 errors) since the wiki has no spell check ...
then you can save ... and then, when it opened back up to a new window,
you can take a final look at what you wrote that anyone else will see."
Whew!
"Hey, come back here, wiki editing is EASY! C'mon, give it a try ...
don't walk away!"
As a Mediawiki trainer trying to bring in the next wave of adopters -
those who haven't edited a wiki yet - I realize we're back in the
syndrome of trying to redesign the customer, rather than redesign the
product - DOH!
----
So, back at ya - what's the problem you see in IPE In Place Editing /
WYSIWYG What You See Is What You Get?
----
> Earlier: "... No problem with a
> SWYSIWYG interface ..."
Peter Blaise responds: Swysiwyg? Whassat?
----
Hello everybody !
I want to create some pages to share only with one friend, using the
features of my wiki (extensions I made).
Here is my idea, but it doesn't work properly. Do you see something wrong ?
1) Create all article as subpage, i.e. Private/article1, Private/article2...
no problem
2) Create a directory called Private, with .htaccess and .htpasswd to
protect it, it works good, my browser ask me for login and password, once
entered, I see the empty folder Private.
BUT I use URL rewriting rules to make pretty URL like
mysite.com/Articleinstead of
mysite.com/index.php?title=Article
Here is my root .htaccess file :
# test if rewrite should stop for
# special directories
RewriteRule ^(images|skins|stats|extensions)/ - [L]
# others...
RewriteRule \.ico|sitemap\.xml|robots?\.txt$ - [L]
# uncomment this rule if you want Apache to redirect from www.mysite.com/ to
# www.mysite.com/wiki/Main_Page
RewriteRule ^/$ /Accueil [R]
# do the rewrite
RewriteRule ^/?(.*)$ /index.php?title=$1 [L,QSA]
So when I call mysite.com/Private/article1, my browser see that there is a
Private folder, and asks the login/pass => oh yessss ! that's OK
...and after it does the redirect => ERROR 500 ! Aaaargh !
What causes the 500 error ?
--
Sylvain Machefert
http://www.tousauxbalkans.nethttp://iubito.free.fr/blog/
> Earlier: "...it would help to use syntax
> coloring (when in edit mode) to make
> the [wikimarkup] tags, and what's
> contained in them be another color..."
Doh - so simple!
I vote for this ... until we have a true, backward compatible
IPE-WYSIWYG = In Place Editing, not in a subsequent window, What You See
Is What You Get, in other words, click and start editing IN PLACE
anything you see on a wiki page.
The color idea is probably still not section 508 compliant (see
http://www.section508.gov/index.cfm?FuseAction=content&ID=12 and so on),
but it would be a super simple aid to novice - and well practices -
editors, nonetheless!
Welcome to mediawiki-l. This mailing list exists for discussion and questions
about the MediaWiki software[0]. Important MediaWiki-related announcements
(such as new versions) are also posted to this list.
Other resources.
If you only wish to receive announcements, you should subscribe to
mediawiki-announce[1] instead.
MediaWiki development discussion, and all Wikimedia technical questions, should
be directed to the wikitech-l[2] mailing list.
Several other MediaWiki-related lists exist:
- mediawiki-api[5] for API discussions,
- mediawiki-enterprise[6] for discussion of MediaWiki in the enterprise,
- mediawiki-cvs[7] for notification of commits to the Subversion repository,
- mediawiki-i18n[8] for discussion of MediaWiki internationalisation support,
- wikibugs-l[9] for notification of changes to the bug tracker.
List administrivia (unsubscribing, list archives).
To unsubscribe from this mailing list, visit [12]. Archives of previous postings
can be found at [3].
This list is also gatewayed to the Gmane NNTP server[4], which you can use to
read and post to the list.
Posting to the list.
Before posting to this list, please read the MediaWiki FAQ[10]. Many common
questions are answered here. You may also search the list archives to see if
your question has been asked before.
Please try to ask your question in a way that enables people to answer you.
Provide all relevant details, explain your problem clearly, etc. You may
wish to read [13], which explains how to ask questions well.
To post to the list, send mail to <mediawiki-l(a)lists.wikimedia.org>. This is a
public list, so you should not include confidential information in mails you
send.
When replying to an existing thread, use the "Reply" or "Followup" feature of
your mail client, so that clients that understand threading can sort your
message properly. When quoting other messages, please use the "inline" quoting
style[11], for clarity.
When creating a new thread, do not reply to an existing message and change the
subject. This will confuse peoples' mail readers, and will result in fewer
people reading your mail. Instead, compose a new message for your post.
Messages posted to the list have the "Reply-To" header set to the mailing list,
which means that by default, replies will go to the entire list. If you are
posting a reply which is only interesting to the original poster, and not the
list in general, you should change the reply to only go to that person. This
avoids cluttering the list with irrelevant traffic.
About this message.
This message is posted to the list once per week by <river(a)wikimedia.org>.
Please contact me if you have any questions or concerns about this mailing.
References.
[0] http://www.mediawiki.org/
[1] http://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
[2] http://lists.wikimedia.org/mailman/listinfo/wikitech-l
[3] http://lists.wikimedia.org/pipermail/mediawiki-l/
[4] http://dir.gmane.org/gmane.org.wikimedia.mediawiki
[5] http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
[6] http://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
[7] http://lists.wikimedia.org/mailman/listinfo/mediawiki-cvs
[8] http://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
[9] http://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[10] http://www.mediawiki.org/wiki/FAQ
[11] http://en.wikipedia.org/wiki/Posting_style#Inline_replying
[12] http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
[13] http://www.catb.org/~esr/faqs/smart-questions.html
Hi,
I have a problem when users try and confirm email address. It warns me that
the email could not be sent even though it was sent fine. After a bit of
searching I found a recommended bug fix. I tried this by editing the
UserMailer file to ignore the error this worked but I noticed i only fixed
that particular error message the same error seems to manifest in different
places.
Apparently this can be caused by a sever time stamp issue. I tryed to
correct the servers time but can't quite figure out how. The server is
running ubuntu Feisty Fawn and is based in Auckland NZ the same place as all
of my clients. The server shows the correct time in the top right conner of
the ubuntu toolbar. Originally the time shown in wiki "my preferences->Date
and Time" was 13 hours out for both Server time and local time.
I added the following lines to my php.ini file
date.timezone = Pacific/Auckland
date.default_latitude = -36.52
date.default_longitude = 195
(Also tried 174)
And the following lines in my LocalSetting.php (Don't have a clue what
these mean but they seem to work)
$wgLocalTZoffset = date("Z") / 60;
$wgLocalTZoffset = 13 * 60;
Now the local time is correct but the server is still out by 1 hour 12:30
instead of 1:30 (I assume this is a daylight savings problem).
So does anyone know how I can correct my time problem? And also how to stop
the error/warning messages from appearing when emails are sent.
P.S.
Hope this doesn't get sent two times. Thanks
--
View this message in context: http://www.nabble.com/Problem-with-email-because-of-server-time-settings--t…
Sent from the WikiMedia General mailing list archive at Nabble.com.
so, the first thing i notice when editing Wikipedia articles these days
is that they're full of <ref> tags that make it nearly impossible to
find the actual text of the article. the problem seems to be that the
entire reference is inline in the text. while this is useful for
locality of editing, wouldn't it be nice if it would be close to the
text, but not inline?
for example, references could be named and referred to with [name], and
then defined at the end of each paragraph:
Wikipedia[wikip] is a project of the Wikimedia Foundation[wmf].
[wikip] http://en.wikipedia.org/
[wmf] http://wikimediafoundation.org/
now, it's still easy to see and change the references, but you can
actually see the article text as well.
for an example from a real Wikipedia article, see
<http://www.mediawiki.org/wiki/User:Kate/ref>.
of course this would require some changes to the core parser to do
properly, but i think the feature is useful enough to be worth it.
comments?
- river.
Hi, I cannot get TeX to work.
I have enabled $wgUseTeX and am getting the error message :-
Failed to parse (Can't write or create math temp directory):
I have created a temp directory under the math directory and have done a chmod 777 on it.
But still get the error.
Many thanks in advance,
Aaron
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Is there any way I can download the Wikipedia donation system and
install it on my own Mediawiki installation? And how much would it cost
me to accept credit cards like Wikipedia is doing?
- --
Regards,
Thomas Anderson
"Quidquid latine dictum sit, altum sonatur"
OpenPGP fingerprint: ED7E 1E98 225A 3FCC 458C B3D7 D625 20E6 F316 BD21
OpenPGP public key: http://todu.dyndns.org/pubkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHYDuV1iUg5vMWvSERAjDuAJ0ScHcZkNA3h6vXLA+R1k0O3rerygCeLENe
+I8DparS5g5C5UYL66m6RLA=
=Q/uf
-----END PGP SIGNATURE-----