This page can be used to request some new functions for the next release, if you found a bug please file it on BugReports. Some UserSuggestions and FeatureRequests have been archived as OccasionallyAskedQuestions or worked into DevelopmentPlans.

---

Perhaps it would be better to use wdiff for diffing.

---

Ewout How about re-writing the WikiMarkup page in the same style as it's done on this Wikipedia page? Is this much clearer?

milky: I know the *WikiPedia markup page. While I think it isn't helpful to rewrite the WikiMarkup page that way (because it only enlarges it), it is also simply not possible to do it, because we cannot put lists or other block markup into table cells.

However their *MarkupByExamples is far superiour to our let-people-click-on-EditThisPage-to-see-it approach, and it's definitely worth considering it. On the other hand making the WikiMarkup page too visual is also not the best solution. I'm currently going to put up an InitPages wiki for updating our distributed default pages.

---

Jeroen I made a couple of tests regarding to images. I use Erfurtwiki-release R1.01b, and MySQL to store Wiki-pages, not the flatfile-option. Platforms: I used a Windows 2000 Professional system, and a Linux RedHat 8.0 system. Browsers: I tested 5 browsers on the Windows system, and one on the Linux system. Images: I used .gif-images (some animated), and a .jpg-image. All images were quite small (1-4 kB).

Testresults:

• Internet Explorer 6 Service Pack 1, tested on the Windows system: images could be uploaded, but are not visible.
• Mozilla 1.5, Mozilla Firebird 0.7, Netscape 7.1 and Opera 7.21, tested on the Windows system: images could be uploaded, were visible, and could also be downloaded without problems.
• Mozilla on the Linux platform: images could be uploaded, were visible and could also be downloaded without problems.
• Images that were uploaded on the Windows system with Internet Explorer, could be seen and downloaded if I used any of the other four browsers I tested. I could also see and download these images in my Mozilla browser on the Linux system.
• Animation of the images was kept :-)

Conclusion: I only ran into one problem: the uploaded .gif-images are not visible in the Internet Explorer browser. Otherwise everything was fine!

Initial display of the images took some time, but after the page was cached this was no problem anymore.

I'd also like to post a suggestion. Isn't it possible to handle the images as files, instead of storing them encoded in the database? For instance in directory /wiki/images ? For instance: [internal://1234.gif] would then point to file /wiki/images/1234.gif. This would make encoding/decoding unnecessary, and I think it would solve the problem of invisible files in Internet Explorer.

Best regards, Jeroen.

milky: The images thingi was already fixed with bugfix release R1.01b0 (or get the CVS version), its discussable if IE was right not to show the images at all; however ewiki was totally broken about writing the image sizes correctly into the returned pages.

For the images: I don't want to have two different databases in ewiki (one for pages and one for files), and we've already discussed that point a lot here. It is mpossible to save images with names, because there is a high risk, that more than two people will upload a 'picture.gif' and therefore overwrote each others file. It's too difficult to work around such things. I'll however could add a patch/ to make a mini-workaround (which then would fall back onto the md5 strings).

milky: Ooops, there is already what you want inside of patches/ - a small description on how to change the code to get the real file names as database entry names. Eventually we could make that a configurable option, but I still need to be convinced that this worked reliable enough to get a core feature.

Jeroen I installed release R1.01b1 yesterday, and made some tests again. The problems I had with Internet Explorer are solved! So, everything is fine, the images are visible in all 5 browsers I tested (see above), and animation is visible in the wiki. On downloading images: Internet Explorer saved .gif as a bitmap (I did not see any other options), so animation was lost there. The other browsers saved as .gif, animation was kept. Super, the new release! BTW - I see the point saving images by their real filenames. Even a db-counter is not completely save if users add simultaneously. I think the md5-string is a perfect solution. I was thinking to use that string as the filename. But, as everything works fine now with r1.01b1, I personally don't feel a need right now for file-handling. The speed is also okay.

Regards, Jeroen

milky: Nevertheless the use-real-filename feature is alreade there, just have a look into patches/uploadedfilenames. It is very easy to change ewiki.php so it used the real filenames. And I believe it could be possible to leave out the md5sum fully there. There can't be any data loss when a file is uploaded multiple times, because the database "WRITE" call is a safe one, in that it does not overwrite things that already reached the database. So it was in fact possible to use some sort of db-counter. I'll probably post a second (more complex) patch/ to accomplish that. And btw, using plugins/binary_store.php it was possible to keep the internal:\\-data files out of the SQL database fully.

---

Tobias: How would I submitt a patch? I have modified some files, mostly to replace constant (english) strings with variables and calls to ewiki_t. Would it be of interest?

Of course it would! :) Just send it to milky, but please note from which release/version you derrived it. If you wrote a new plugin you could also go to the DevelopersPage, create a new page about it and attach/upload it so other users could review and adopt it.

---

integration with Geeklog -- refactored to StaticPages

---

*anonymous: The main menu is not available for editing. There should be a link for editing the main menu too. The menu page should be integrated into the ErfurtWiki!

milky: Once again, the "ErfurtWiki" is a library, neither a menu or a specific page layout belongs to it. What you can see here is the example-1 wrapper around the ewiki script. However a "MainMenu" has now been integrated into the distributed example-1 wrapper (experimentally).

HL: I implemented a dynamical Menu in my WIKI (see Seitenlayout). The Menu is not editable now. But i think there should be a way to include the array i use there from an included Wikipage to make it editable. The Problem i have are the filenames (menu.1 menu.2 menu.3 etc...)

---

Feature Request: Invisible tables

Since I am using ewiki as a general purpose engine for my site. I will inevitably need some kind of markup to separate visble and nonvisible tables. Any ideas for what could be used for this? I'm using CSS extensively so a general div markup would serve this purpose and others quite well. -APF

milky: There is probably no way to do that with current markup, but the older mpi_complextbl extension may already support invisible tables. However I think we could introduce some other table extensions - there is a nice markup comparison on WikiPedia. -- milky

---

Feature Request: Full Wiki Markup Implementation

I'd like to see the double-space/tab -> preformatted text wiki markup has been requested for sharing sourcecode. Currently a double space wraps text in <tt> tags. Preformatted text with the <PRE> tag can be selected by preceeding it with 4 empty lines and following it with 2 empty lines. This works, but square brackets ([]) and WikiWords must be escaped with exclamation points. Current DevelopmentPlans call for the the spaces and tabs to be used for indentation of some sort in the future.

milky: I believe that prepending a piece of text with one or more spaces just to make it < pre >-text could become a lot of work, if your code snippet gets longer than 10 lines (it is easy with my w3m/joe editbox, but probably annoying if one uses NN or IE). So I think spaces could/should be reserved for something else.
However the current "4 empty lines" will disappear again (horrible, isn't it?), and we must introduce something more useful soon. In another wiki I saw use of "{{{" and "}}}" to enclose < pre >-text, but we should really compare and summarize to finally decide which Wikis solution is the best (and most widely used) one.
The brackets [] now work with < pre >-text if you handle work over to the new plugins/rendering_pre (see CVS release). The bug occours because the last step in rendering a page is always to apply WikiLinks (what the [] actually are), which is a very high speed enhancement, but suddenly led to that bug.

---

The discussion on the WikiMarkupStandard has moved.

---

Hierarchical page structure aka subpages -- refactored to SubPages

---

Images and their Filenames.

HL I use flat-files. When uploading an image EWiki generates not readable names like internal:\57b96dcf238a0bfbd86ffe44b270d9f7.jpeg. Perhaps this is usefull for having unique filenames, cause ewiki is using just one directory for all files. Another Wiki i use (JSPWiki) is using readable "normal" filenames. The difference is, that these files get stored in a Subdirectory which name is the same as the page where that file or image got been uploaded and another *SubDir with the Name of the uploaded Filename. The Version get named 1.ext 2.ext ... (e.g. this Page and a uploaded aimage.png

data                    Main Directory for uploaded Files
  UserSuggestions       Subdirectory with name of *WikiPageName
     aimage.png-dir     Subdirectory with name of uploaded image/file
        1.png           Version 1 of uploaded image/file
        2.png           Version 2 of uploaded image/file

This makes things readable

---

Mateusz: A really tiny request - so that images' ALT field would be enclosed in sqare brackets (or something else). It'd make them easier to be distinguished from normal text in text browsers (especially links)

milky: We already have it! :) Just put some text enclosed in quotation marks beside the internal:\\md5md5md5md5 inside of the square brackets (you could also use the dash syntax), this will get the alt="" and title="" text later.

Btw, try w3m - it is the coolest text browser on earth!

Mateusz: Uh, oh. I didn't understand this paragraph properly last time when reading. Now that I think I got it, I'd like to answer. That is, I meant square brackets to be *enforced*/default, so that when not changed, pictures' ALT's would be encapsulated this way. If not, most contributors'n'server-owners would not have any reason behind doing this way, not knowing some people find it lot easier to read.

Btw, hmm.... I think links is cooler... :D (and, btw, in certain situation I have no alternative)

---

Revision control

Interesting wiki, it is missing one major feature though as far as I can tell. This is storage of the diffs for past revisions so you can revert back to old versions of pages if needed, and see the differnces easily. Maybe I am just missing it?

Andy: You are, it's under PageInfo at the bottom of every page. EWiki actually stores full copies of each revision and has routines to diff between any two revisions, a plugin allows configurable diffs.

jbw: Hmmm... storing the full text of each revision could make for a very large db for a busy/large wiki. Maybe it should store just the diffs?

jbw: I am not sure that accessing older pages is that frequent an operation that it needs to be speed optimized. I think requiring diff to be present on the system is reasonable as well.

---

jbw: Another idea for the evolotion towards a CMS, a polling/survey module.

• Andy: I've had users request this, but it's not important enough for me to write it, I would use it if it were available. Polling and "Rate This Page" would both be handy.

---

jbw: Also, something seems wrong with allowing the text to be wrapped by the browser. In Mozilla, I have to scroll vertically to read the text where it really should be wrapped to fit the browser size. In the converse this editing box takes up too little of the size of the screen before hitting that '+'. It should use more to start with.

I saw the wrapping problem about five days ago and it was fixed about four days ago.

---

Aestectic Issues

Two aestectics issues, firstly the *CancelEditing link should probably be set up to render as a cancel button. Secondly, is it on purpose the phrase 'Don't care about how it looks...' is itself not quite correctly written?

• Andy: I use "Be brief, be clear, and keep it simple. You can add *LiveWebMarkup later if you think it is necessary." in my installation.

jbw: What I wound up putting was "It is GoodStyle to write good content first, with out worrying about formatting for now. You can add WikiMarkup also later if you think it is necessary.". I also edited the GoodStyle page. It would probably be good if this string was a parameter, as I put text after it that others running the wiki on the same box may not really want, and it seems best to use a shared copy of it.

Also some more most, aestectics issues I have had come up:

It should be possible to set the text 'Thank you for your contribution!', to style different then the rest to make it distinct (different color etc.)

• Andy: milky will add or not add a class in the code when he looks at this suggestion, in the meantime, $ewiki_t*<each language>["THANKSFORCONTRIBUTION"] holds the text and you can add the class/styling you would like it to have there.

The use of the link at the top of the page for the page title to get to the pages linking to the page is a little odd. When you are on the page saying 'Pages link to *PageName' probably only *PageName should be the actual link and not the whole verbage.

• Andy: except that I style that link I would agree.
• milky: True, but would effort to much code to fix it. We use a standardized _mk_title() now, and making an exception for cosmetical purposes I'd find sub-optimal.

On the diffs page:

• Andy: Set $ewiki_config["print_title"] higher to get more linked titles.

• jbw: Ah, ok, of course it them has the same aestectic issue as the above link, that milky does not want to special case.

• Andy: Done

ring guest users the first parts of the domain names.

• Andy: Looks like a bug, my deployment doesn't have the button appearing, though I don't know why, I'm copying this note to BugReports.
• milky: The "fetchback" button is there to ease reconstruction of damaged pages (some kiddies cleared the page), and I think, everybody should be able to get the previous version back. The "fetchback/" is nothing but a renamed "edit/" action.
• jbw: What I mean, is that you should not be able to fetchback the current version, you or at least some level of users, should be able to restore/fetchback old versions for sure. BTW, why did you use slashes for the actions? Why did you not do something like ?p=*PageName?a=Action ?

The world wide web has no time zone all users are in, so the updated pages should give a time zone, and perhaps should default to showing everything in GMT/UTC?

• Andy: We had even considered Internet Time but that hasn't been implemented. For now the times are as per the server, which makes sense for anything less than international.
• milky: We should think about making it configureable, but this is not easy, because ewiki again suffers from its "library mantra". In PHP it is possible to set the locale (which however cannot be determined from the http clients' request headers), but yoursite.php should do that, not ewiki. If we however choosed standard GMT/UTC time as default (which I would call "internet standard") then again a few users weren't satisfied. I think this should become a fragments/ feature.
• jbw: Well I thinking "Internet time" is just a marketing gimick, but many things use UTC/GMT, from shortwave radio, aviation, to process control, and the military. In any event

since the time zone may not be known to the user can we at least print out the time zone as part of the information on the updated pages list? Later, maybe showing everything in GMT should be the default, and the user can set some cookies that contain say their name for the author field, and the time zone they want to see things in.

How can I style the 'cancel editing' link to look like the buttons for save and preview? (Still not sure how to this from before, tried using css but am not good enough with it yet I guess).

• Andy: Well, you can't get it exact without restyling the buttons for save and preview, which is somewhat browser dependant. Once you've done that, you just need to identify that button and set it to display:block and the same styling, I'll try to add some of my code here later.
• milky: I've added <a class="cancel" href="... to the CVS version, so this is now possible (use .wiki.edit a.cancel {...} to style it).
• jbw: Great, when will the next release be?
  • milky: Nobody knows. Depends mainly on a stabilized rendering kernel (see for example the broken <hr> support Andy mentioned above).

Please package the public domain core, and plugins seperatly from the gpled and lgpled stuff.

• Andy: Why? As long as we are legally ok I think it is more functional to distribute them all together.
• milky: For the LGPL stuff I also don't see any problem, I've asked FSF about GPL code, and that is also fine in some cases. Therefore our current policy is to throw everything into plugins/gpl/ if necessary. Splitting up the main tarball only complicated downloading. (Note: there is already that extra tarball, but only to keep the main small; only smilies, bloat plugins and so on would go there). We only must take care to mark all the non-PD stuff correctly!
• jbw: Well, a number of reasons, it would make it easier to include in public domain software collections. I am involved in some groups that are advocates of the public domain, and they would be drawn to this wiki by the fact it is in the public domain. Also, I do consulting in some places that do not allow GPLed stuff, and strickly

speaking even downloading it to their systems is not allowed. It would make it easier to get ewiki used in these places. At the very least can you include a script that can be run to delete the non PD stuff?

Oh, another idea that would be nice, would be if somehow the wiki could reconize conversational style like above, and assign each 'voice' in the conversation a different color text, or background shading or something.

Andy: If you really want forced disscussions, try my aview_posts.php plugin.

---

Bandwidth issues

It seems every page is transmitted with all the style sheet information each time, would it not be better to include these from a unique url, so the browser would just cache and download it once?

milky: That's only a problem with the default layout. The reason for this is, that there is the general rule of not adding too much images/pictures into the distribution tarball. And all the example-* layout scripts are also required to be stand-alone ones, and therefore shouldn't carry a separate style sheet.

If I wasn't too lazy I could of course change it for this demo installation, but such a change would likely be overwritten by another days update from the CVS tarball.

Btw, we had already thousands of discussions about the current ugly yellow example "layout". And as I always say, it's just an example and not worth to put much effort in. (Writing a better image-less default layout is however worth putting effort into ;)

---

TOC: caption + swap indent

Jochen: Playing around with include("plugins/aview/toc.php") I noticed that the smallest headlines are most left. Very unusual, isn't it? I prefer small headlines beeing indented, not big ones (= 3-n instead of n-1).

And I'd like to have the opportunity to use a caption like "Content" or "Inhalt".

So I tried myself, it works, but please look carefully on what I did since I've no clue how the ewiki interna are working:o)

milky: Thanks for that! Looks nice, I'll upload it straight into CVS. (Me didn't notice the headline ordering bug, btw.)

But, I'm probably changing the constant to be boolean, and add the typical $ewiki_t[] strings - though I found your use of the constant pretty refreshing :-)

Jochen: Just got it from cvs - looks much better now. The typical $ewiki_t[] strings are something I haven't "wasted" my time with till now:o)

Just my 2 ct to my suggestion vs. your changes to it: I really don't like hard-wired define() statements in plugins. If I include the plugin I

• get a notice "already defined" or
• must disable all notices which I don't like most of the time (who knows what else wents wrong?) or
• must edit the plugin code which I don't like coz after each update I have to do it again

So my refreshing use:o) of the constant avoids this and enables the user to print any caption he wants. Maybe someone likes "What is it all about?" or "Inhaltsverzeichnis" or "Jump to" or whatever. Think about it if you like. In any case it's now better than before. Thanks.

milky: But constants are actually there for exactly that purpose (getting overriden from somewhere earlier). I don't know why they made them yield warnings at all; we could add an @ before every define() to make it work, but that makes the code pretty unreadable. Whatever, using $ewiki_t[] instead if one constant has the advantage that not you define() how the toc headline looks, but that your visitors get the headline they want - that is you would see "Inhalt" while someone from Britain would surely read "Content" instead. You simply couldn't do that with just one constant, though your approach may be more useful for other fixed strings.

Jochen: I'd be happy with some @ :o) Think of normal users simply trying to get it working. Personally I don't feel good if I can't get rid of some warnings or notices. And I feel even worse turning them off completely. Btw - you're right with visitors from different countries, someone from Britain would read "Content". But he wouldn't be able to read one of the (german) headlines or the content itself, so I didn't thought about that:o) Alright then, let's stay with the $ewiki_t[] but add some @ to the right define() statements (which are leading the functional code anyway and therefor wouldn't be very unreadable).

---

Advanced highlighting

(If there is a better place to post modified code please tell me:o)

Jochen: Still playing around with the search highlighting I found another optical bug and noticed that I want to highlight in different colors. So finally I changed another three lines (and added an comment how to style the output). This time I really tried to understand how the plugin works (thank god there's not too much ewiki interna) so please tell me if you'd like to change my suggestion before commiting it to the repository. Here is it:

milky: Buyed! I moved the bugfix comment in the CVS upload notice however. We in fact had once a place to upload code, but now it seems to work this way too (at least unless some Win browser scrambles new lines or so). Try the '<CODE>' tags instead of '<PRE>' so no *WikiLinks appear. We used to have the upload/downloads plugin enabled once, but that wasn't very good looking. And Jochen, I'd say you could as well upload directly into CVS :)

Jochen: Thanks. The CVS upload notice is a good place for the changes comment. Directly uploading in the cvs would probably force me to

• install another cvs-client on my win98 and win2k machines
• install a ssh client or something
• create an account in the cvs

I think I'd rather spend my time with making some more suggestions instead of doing that - if it is ok for you:o)

Btw: I noticed that you used "highlight marker searchword-n" instead of my "highlight searchword-n". Not that I care for that, but may be there is something to lern? Is there a special reason?

milky: Yep, I added "marker" again - mainly for compatibility reasons ("We had this before, we should keep it..."). Don't know if that term is in such wide use, but I have seen it already; and people may like it more than "highlight" (which we also use for other purposes elsewhere). In this case it boils down to leaving users the choice which class name to use.

Yes, on Win it's a bit more effort to get a CVS client running; but anyhow I have no problem, if you keep posting code here - ...just keep doing so! ;-)

Jochen: Just missed it: What about an option in PowerSearch to search in "old page texts"? For the I'm sure to have seen this but now it obviously has gone away - where has it been? cases...

MarioSalzer: Can't remember of such a thing (but we probably had such a checkbox somewhere, else it was a hint in one of the README files). It just can't be supported with our current database interface, which always only scans the very last revision of every page (maybe the SQL backends actually sometimes reveal text from an older version).

We could add a specialized plugin for that task, but this was really really slow then (it had to scan and open every page and every version of every page separately).

Jochen: Don't know if it does or has ever exist, I simply couldn't find it. Would it be complicated and/or a good idea to add a param to the interface (preset to "only last version" as it is now) which could be switched to "all versions" or "all versions since date x"? The plugin would need to implement mostly the same code, and that for all the db-backends. And that might not be worth the effort.

MarioSalzer: Adding it to the default interface is a bad idea, as it means a cluttered interface for visitors (just a form field and a submit button is always the best you can do). Of course we have the PowerSearch interface as well, and it may make sense there; but I'm still onto finally crafting the FutureSearch first, and I'm not sure if I can hack this into there too (what you want is a bit tricky to melt with the more simple code). So it would probably become a separate feature instead.

Do you want it for your users, or just as administrative task (in the tools/ or WikiCommander, or just ewikictl eventually)? I already planned for a more complex search and masking feature to make a file selection list from, in the url:/tools/ area.

Btw, there is no dependency on one database, we simply utilize our ObjectOrientedDatabaseInterface and don't care about the store. We plan on making some plugins specifically for sql/ backends, but that always only as secondary alternatives (any search feature makes a candidate for such an optimized thing, after all that's the main purpose of RDBMS and SQL).

---

Section editing

First of all, thanks for this application. The flexibility is awesome. However I really miss the possibility to edit single sections of a page. Editing long pages becomes quite hard without that. It would be great if that could be implemented. Best wishes, Christian

MarioSalzer: Yes, that's a nice idea; but it is a bit complicated to get something like this work reliably. I've seen some notes over at WikiFeatures:, but I'm not sure if anybody ever has implemented this at all. However, it's now on the *ToDoList...

BobRomeo: Isn't this a bit like SubPages ?

---

Htmlentities

wouldn't it be good to escape more htmlentities per default?

I for example use:

# replace more htmlentities:
$ewiki_config["htmlentities"] = array(
    "&" => "&",
    ">" => ">",
    "<" => "&lt;",
    "ä" => "&auml;",
    "ö" => "&ouml;",
    "ü" => "&uuml;",
    "Ä" => "&Auml;",
    "Ö" => "&Ouml;",
    "Ü" => "&Uuml;",
    "ß" => "&szlig;",
    "·" => "&middot;",
    "©" => "&copy;"
);

BobRomeo: Why should you do this ? It uses more space in your database

---

Underlined text?

You can use

__

and

**

to make text bold..

why not use

__

to make text underline? (<u></u>)

BobRomeo:

**

is Strong And not Bold In CSS you could make Strong look like Bold and Italics. I think with plugin *RescueHtml.php you just can use the <u> version.

---

BobRomeo: eWiki should be easy to integrate. Then parts of ewiki.php that are to be customized should be in config.php. Or they should be in example-1.php and in ewiki.php they should be conditioned like so:

if (!defined("EWIKI_NAME")) {

... ...

The reason for that is: When someone has integrated a prior version (looking at the future) they can look more easily for differences. This applies also to all the settings one has made with the SetupWizard.

mario: The conditional define is unneeded in current PHP, because constants can be defined just once and then are immutatable.

I don't understand your comment about looking for differences yet. Would the if() make it more readable; or how would it identify new settings in practice?

Maybe a standardized comment formed /*@NEW:R1.05a*/ would help better in this case?

BobRomeo: I forgot that about the defines. /*@NEW:R1.05a*/ is fine.
For the SetupWizard: The same standardized comment and maybe a larger comment up front, like a ChangeLog, for the newest version only. The rest maybe at the end.
I've come to the conclusion that when you start with eWiki, you can use it. With upgrades you cannot, because there are too much trees in the forest :-)
If in a future version there's more comments then could you can see in a glance if there are new defines in a new eWiki version.

---

BobRomeo: ewiki.php: $ewiki_t["nl"]

           "EDITTHISPAGE" => "BewerkDezePagina",
           "APPENDTOPAGE" => "VulAan",
           "BACKLINKS" => "BackLinks",
           "EDITCOMPLETE" => 'De bewerking is bewaard, klik <a href="$url">hier</a> om de bewerkte pagina te zien.',
           "PAGESLINKINGTO" => "Pagina's linken naar \$title",
           "PAGEHISTORY" => "PaginaInfo",
           "INFOABOUTPAGE" => "Informatie over pagina",
           "LIKEPAGES" => "Pagina'sZoalsDeze",
           "NEWESTPAGES" => "Nieuwste pagina's",
           "LASTCHANGED" => "laatste bewerking op %c",
           "DOESNOTEXIST" => "Deze pagina bestaat nog niet, klik op BewerkDezePagina om deze aan te maken.",
           "DISABLEDPAGE" => "Deze pagina is momenteel niet beschikbaar.",
           "ERRVERSIONSAVE" => "Sorry, tijdens de bewerking van deze pagina, heeft iemand anders
                al een gewijzigde versie van deze pagina opgeslagen. Ga terug naar het vorige scherm
                en kopiëer de wijzigingen naar het plakbord van de computer, om deze in te voegen,
                nadat je de pagina ververst hebt.",
           "ERRORSAVING" => "Er is een fout opgetreden bij het bewaren van de wijzigingen. Probeer opnieuw aub..",
           "THANKSFORCONTRIBUTION" => "Bedankt voor je bijdrage!",
           "CANNOTCHANGEPAGE" => "Deze pagina kan niet gewijzigd worden.",
           "OLDVERCOMEBACK" => "Vervang de huidige versie door deze oudere versie",
           "PREVIEW" => "Voorproeven",
           "SAVE" => "Bewaren",
           "CANCEL_EDIT" => "Annuleren",
           "UPLOAD_PICTURE_BUTTON" => "Afbeelding uploaden &gt;&gt;&gt;",
           "EDIT_FORM_1" => "Het is <a href=\"".EWIKI_SCRIPT."GoedeStijl\">GoedeStijl</a>
                om gewoon met schrijven te beginnen. Met <a href=\"".EWIKI_SCRIPT."WikiOpmaak\">WikiOpmaak</a>
                kun je later de tekst vorm geven.<br />",
           "EDIT_FORM_2" => "<br />Schrijf geen dingen die anderen kwaad kunnen maken.
                En onthoud dat je niet geheel anoniem bent op internet (meer informatie over het
                '<a href=\"http://google.com/search?q=my+computers+IP+address\">IP address</a>' van je comuter
                vind je bij Google).",
           "BIN_IMGTOOLARGE" => "Afbeelding is te groot!",
           "BIN_NOIMG" => "Dit is geen bestand van een afbeelding (bestandsformaat niet acceptabel)!",
           "FORBIDDEN" => "Je hebt niet genoeg rechten om deze pagina te benaderen.",

btw. there are no german texts for the last 3 variables !
ps. this is tested in ewiki.php !

---

BobRomeo: Added some suggestions to BugTrackingSystem.

---

non-english

• Spanish
• FragenUndAnregungen
• FehlerBerichte