I appreciate all of the good feedback I've seen here about Creole 0.1.
I have added a few clarifications to the Creole 0.1 spec:
Bold and Italics:
Bold and Italics should be able to embed in lists and one should be
able to make links bold and italic. Bold and/or italics can span
lines, but not span across lines in lists nor across different
paragraphs.
Lists:
Bold, italics, links, pre can be embedded in lists. Whitespace is
optional before and after the * or # character, however a space is
required afterwards if someone wishes to start a list element with
bold text. It is recommended to have support for a depth of at least
five levels.
About unordered lists and bold: a line starting with ** (including
optional whitespace before and afterwards), immediately following an
unordered list element a line above, will be treated as a nested
unordered list element. Otherwise it will be treated as the beginning
of bold text. Note that bold and/or italics cannot span lines in a
list.
-
To see the changes in context, please view:
http://www.wikicreole.org/wiki/Creole0.1
Again, we do not wish to require a space after a list element in
general, because many users forget to do this and we wish to make
Creole as forgiving and user-friendly as possible, even if it means
making parsers a bit more complicated.
Chuck
I posted a draft of WikiCreole 0.1
<http://www.wikicreole.org/wiki/Creole0.1> to wikicreole.org and we
believe all the rough edges have been smoothed out, but are still
seeking comments and criticisms from the wiki community.
Please either reply on <http://www.wikicreole.org/wiki/Talk.Creole0.1>
or just email me. We plan to release a final spec on **Monday**, so
last day to comment on Creole 0.1 is this Sunday.
Chuck
I've been poking around mediawiki for a couple months now. I am working on
a project that has a lot of customization demands and am running into some
quicksand. Any help or pointers would be appreciated. I came here because
this all seemed to complicated for IRC...
1. Alternate Editor/New Editor/Editor Script/Editing Form
I need to set up a more restrictive editor as a linkable option to the usual
editor. By more restrictive, I mean you essentially build the article with
text inputs and drop down menus.
I've found the showEditForm() function in EditPage.php and the FCKeditor
extensions, but am at a loss which way would be best. Ideally I would just
create the form, feed it to a script which recombined all the values, and
sent it on into the regular editing/updating mechanism.
2. Text Queries/Query Content/Get Article Content from Database
Part of this project is to maintain a flatfile mirror of the articles in one
of the wiki namespaces. This includes writing out files when they are moved
into the particular namespace. I'm finding the db calls to be confusing. I
have the article id & title, what am I looking for to get the article text?
This is being written as an extension.
~ grayside
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
You are receiving this email because your project has been select to
take part in a new effort by the PHP QA Team to make sure that your
project still works with PHP versions to-be-released. With this we
hope to make sure that you are either aware of things that might
break, or to make sure we don't introduce any strange regressions.
With this effort we hope to build a better relation between the PHP
Team and the major projects.
If you do not want to receive these heads-up emails, please reply to
me personally and I will remove you from the list; but, we hope that
you want to actively help us making PHP a better and more stable tool.
The final release candidate of PHP 5.2.0 was released today, it can
be downloaded from http://downloads.php.net/ilia/. If you discover
any problems with this release please notify PHP's QA team at "php-
qa(a)lists.php.net".
In case you think that other projects should also receive this kinds
of emails, please let me know privately, and I will add them to the
list of projects to contact.
Best Regards,
Ilia Alshanetsky
5.2 Release Master
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFFCaEcLKekh381/CERAmXFAJ45vPIOzjpOLOFJFP5ZVwCvGL/GmgCdHL/b
4XQylxmOZTNrkOMzKHPeCDw=
=L04u
-----END PGP SIGNATURE-----
Is this normal?
when running rebuildMessages on my 1.71 mediawiki i get additional rows
within table text with "old_namespace" values = 0
i run rebuildMessages this way:
php5 maintenance/rebuildMessages.php --update languages/Messages.php
HeinzJ
The WiktionaryZ project has made rapid progress in the last few weeks,
thanks in no part to our growing team of developers, now including
myself, Peter-Jan Roes, Karsten Uil, and Rod Smith. There's a growing
community at http://www.wiktionaryz.org/ , and our intrepid editors
have already added more than 20,000 words to the original GEMET
database. While there are still many glaring deficiencies and lacking
key features, the WZ core model of terminology works.
Key functionality added to the code in the last few weeks includes:
- Basic versioning. All tables now have versioning information, based
on a transaction model where each record has an associated transaction
record. It is possible to get a simple aggregated history view on a
per-page level; more advanced history views are to come.
- Object identifiers. Key tables now have object IDs associated with
their records. These object IDs are themselves linked to a
database-independent universally unique identifier (UUID), which
allows us to expose data through APIs without using IDs that may not
be available in a target application. The object model also provides
us with a flexible method of grouping or annotating entitites.
- Sticky UI. Rod A. Smith has hacked a nice feature where your view of
the "tree hierarchy" in WiktionaryZ will remain persistent if cookies
are enabled. This allows editors to see only the information relevant
to them.
- New import scripts. We have some exciting new scientific data
sources that will be imported into WZ soon (target date is mid/end
October).
- Small things: hacks for search, adding languages, finding words that
need translation. Splitting exact meanings and imprecise ones.
Improved changelogging.
The versioning is arguably the biggest step here and puts us one step
closer to becoming a true wiki. Next in the roadmap: rollback and a
better class model for ontologies.
Now, let me be absolutely clear: WZ is still pre-alpha code, and it's
messy. We're still extending an old MediaWiki (not really a big deal
since there are relatively few points of attachment, but we'll still
need to fix it), and we have very little documentation. That said, if
you follow the instructions below, you should be able to get your own
edition up and running.
1) Download http://epov.org/temp/wz-sep14.tgz - it's a big file
because it contains the entire database _and_ uploads of
wiktionaryz.org.
2) Decompress the file to a directory in your Apache DocumentRoot.
3) Create and import the database from the .sql file in the dump (if
you don't know how to do this, you should probably stop here).
4) Correct LocalSettings.php $wgDBname to point to the correct
database and authentication, and fix the paths (/www/wz) to point to
the appropriate subdirectory of your DocumentRoot.
5) Run the wiki. Create a user through the "Create an account"
interface. Give the user the "wikidata" permission by inserting a row
into the user_groups table with the ug_user being the user ID of the
user you just created, and the ug_group being 'wikidata' (you should
probably give it 'sysop' and 'bureaucrat' rights as well).
You should now be able to edit the relational data in your WZ
installation, and can start playing with the code, particularly in the
extensions/Wikidata/WiktionaryZ subdirectory. You may want to get
updates to that code from the Wikimedia subversion repository.
I am currently unavailable but will be back on Sep 20 if you have
questions or problems. We are happy to accept new developers and will
prod Brion for you to give you Subversion access if necessary. ;-) We
also always have fun and interesting small and large projects to work
on.
--
Peace & Love,
Erik
An automated run of parserTests.php showed the following failures:
Running test TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test TODO: Link containing double-single-quotes '' (bug 4598)... FAILED!
Running test TODO: Template with thumb image (with link in description)... FAILED!
Running test Template infinite loop... FAILED!
Running test TODO: message transform: <noinclude> in transcluded template (bug 4926)... FAILED!
Running test TODO: message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test TODO: HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test TODO: HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test TODO: HTML nested ordered list, open tags (bug 5497)... FAILED!
Running test TODO: Parsing optional HTML elements (Bug 6171)... FAILED!
Running test TODO: Inline HTML vs wiki block nesting... FAILED!
Running test TODO: Mixing markup for italics and bold... FAILED!
Running test TODO: 5 quotes, code coverage +1 line... FAILED!
Running test TODO: HTML Hex character encoding.... FAILED!
Running test TODO: dt/dd/dl test... FAILED!
Passed 412 of 429 tests (96.04%) FAILED!
Hi,
I tried to find some info about storing Java applets on the Wikimedia
servers, and was not very successful. Maybe somebody here can help me out.
From what I understand, applet/jar files are not welcome on the
servers, because there is no valid/convincing use case. However,
thinking about an interactive "lab session" for Wikiversity, and seems
to me a Java applet would be the best fit for what one would look for.
Actually, there are some GPL sourced applets for physics demos out
there, that show the possible usefulness of those for Wikiversity, eg.
look at
http://galileoandeinstein.phys.virginia.edu/more_stuff/Applets/ProjectileMo….
Anybody want to chime in on this? Maybe there is a better way to
implement an interactive page like that, and I just have not found it, yet.
Andreas =:-)
At the moment we have a spam-problem. People or PCs are adding dayly
users with no edits. Mostly they look like TheUserViagra with the Email
TheUserViagra(a)someGMX.net
I would like to delete all users with no edits before updating to
mediawiki 1.71 and adding a CAPTCHA into the add new user dialog.
Who have some Ideas?
- SQL clauses
- ....
THX, HeinzJ
when running
php5 maintenance/rebuildMessages.php rebuild
/srv/www/htdocs/wiki/languages/Messages.php
i get this Error
PHP Notice: unserialize(): Error at offset 0 of 96449 bytes in
/srv/www/htdocs/giswiki/en/maintenance/InitialiseMessages.inc on line
232
HeinzJ