phpwiki-talk

[Phpwiki-talk] simple regression test

[Steve W. <sw...@wc...>]

I found lwp-rget, which will fetch all the pages and write them in the
current directory. It's bundled with the Perl LWP, so if you have the LWP
installed you probably have lwp-rget (plus others).

using this like so:

lwp-rget --verbose http://wcsb.org/~swain/tmp/phpwiki/

dumps all my pages into the current directory. By dumping into a temporary
directory, making code/page changes, and then dumping into a second
temporary directory, I can run diff on the two directories and see the
difference in page output. 

It could use some refinement, but it's a start.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

more on Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Steve W. <sw...@wc...>]

Well, this might not count for much, but the http: solution does not work
in Emacs' w3 mode. This makes me nervous that it will break other
browsers... it also won't let me use lwp-rget to write a regression test,
since the URLs all come out like this:

[swain@localhost tmptmp]$ lwp-rget --verbose
http://127.0.0.1:8080/phpwiki/
Use of uninitialized value at /usr/bin/lwp-rget line 222.
START     = http://127.0.0.1:8080/phpwiki/
MAX_DEPTH = 5
MAX_DOCS  = 50
PREFIX    = http://127.0.0.1:8080/phpwiki/
http://127.0.0.1:8080/phpwiki/ ............................. index.html
 http:index.php ............................................ *outsider*
 http://127.0.0.1:8080/phpwiki/images/wikibase.png ......... wikibase.png
 http:index.php?full=FrontPage ............................. *outsider*
 http:index.php?WikiWikiWeb ................................ *outsider*
 http:index.php?HowToUseWiki ............................... *outsider*
 http:index.php?AddingPages ................................ *outsider*
 http:index.php?SandBox .................................... *outsider*
 http:index.php?RecentVisitors ............................. *outsider*
 http:index.php?RecentChanges .............................. *outsider*
 http:index.php?MostPopular ................................ *outsider*
 http:index.php?ReleaseNotes ............................... *outsider*
 http:index.php?edit=FrontPage ............................. *outsider*
 http:index.php?info=FrontPage ............................. *outsider*
 http:index.php?diff=FrontPage ............................. *outsider*
 http:index.php?FindPage ................................... *outsider*
index.html


I'm looking for another solution. Perhaps the way the diffurl is encoded
can be changed:

      if($isnewpage) {
         $newpage[$k++] = "\t* [$pagename] (new) ..... $remoteuser\r";
      } else {
	 $diffurl = "$ScriptUrl?diff=" . rawurlencode($pagename);
         $newpage[$k++] = "\t* [$pagename] ([diff|$diffurl])
..... $remoteuser\r";
      }

but I don't think there's an easy answer there either, and I don't want to
kluge it with an if/else...


sw

On Tue, 10 Oct 2000, Neil Brown wrote:

> On Monday October 9, aho...@in... wrote:
> > Steve,
> > 
> > > This patch sounds like a good idea: no default server name. Another "why
> > > didn't I think of that?" idea. Anybody see any holes in it?
> > 
> > this breaks the diff links in RecentChanges.
> > Unless we invent a new wiki-syntax they will remain broken.
> > 
> > /Arno
> 
> Ahhh.. that was the problem with my diff links.  I hadn't had a chance
> to look into them, and it didn't click that the break might be related
> to that change.
> Instead of
> 	   $ServerAddress = "";
> use
> 	   $ServerAddress = "http:";
> 
> That has the same effect of using relatvie URI's, doesn't break the
> diff links in RecentChanges
> 
> NeilBrown
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Steve W. <sw...@wc...>]

Done. Ran tests on all the pages (I hope) and found no errors.

It has occurred to me lately that a Perl-based regression test is
possible... using the LWP one would only have to enter the FrontPage, and
let the script retrieve all pages and compare them to a previous set. A
diff output would show any changes in the way pages render. It would
remove the uncertainty of whether you tested all the pages or not...

sw


On Tue, 10 Oct 2000, Neil Brown wrote:

> On Monday October 9, aho...@in... wrote:
> > Steve,
> > 
> > > This patch sounds like a good idea: no default server name. Another "why
> > > didn't I think of that?" idea. Anybody see any holes in it?
> > 
> > this breaks the diff links in RecentChanges.
> > Unless we invent a new wiki-syntax they will remain broken.
> > 
> > /Arno
> 
> Ahhh.. that was the problem with my diff links.  I hadn't had a chance
> to look into them, and it didn't click that the break might be related
> to that change.
> Instead of
> 	   $ServerAddress = "";
> use
> 	   $ServerAddress = "http:";
> 
> That has the same effect of using relatvie URI's, doesn't break the
> diff links in RecentChanges
> 
> NeilBrown
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] misc pending patches / restructuring

[Neil B. <ne...@cs...>]

On Monday October 9, sw...@wc... wrote:
> On Mon, 9 Oct 2000, Arno Hollosi wrote:
> 
> > 
> > Nested DefinitionLists by Neil Brown:
> > Looks ok.
> > Note: this still relies on tabs. I think we should get rid of tabs ASAP.
> 
> When I added tabless syntax, I skipped term/defs because there was no
> clear solution, and nobody uses them (even on c2.com, and in regular HTML
> pages). Ward probably coded them in in 1995 when people were still
> exploring HTML and might have used them. Anyhow, I will take a look at
> that too tonight. There should be a simple syntactic solution.

Gee.. I use defintion lists all the time!!!  Must just be the way my
brain works.

The meatball wiki
  (  http://www.usemod.com/cgi-bin/mb.pl?TextFormattingRules ) 
uses:

   Term with indented definition: [without a blank line between term and definition] 
   
   ;Term:Definition (indented)
   ;;Term (indented):Definition (indented two levels)
   ;;;Term (indented twice):Definition (indented to third level)
   
   ...which looks like: 
   
   Term
         Definition (indented) 
         Term (indented)
               Definition (indented two levels) 
               Term (indented twice)
                     Definition (indented to third level) 

This looks like a reasonable syntax and is in-line with the *** and
### syntaxes for other nested  lists.

>  
> > SearchType patch by Neil Brown:
> > The actual patch is ok. If a search box should be included in the default 
> > browse.html should be discussed.

I'm quite happy with leave browse.html alone.  I just included it in the
patch to demonstrate how I would use the extra functionality.

NeilBrown

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Neil B. <ne...@cs...>]

On Monday October 9, aho...@in... wrote:
> Steve,
> 
> > This patch sounds like a good idea: no default server name. Another "why
> > didn't I think of that?" idea. Anybody see any holes in it?
> 
> this breaks the diff links in RecentChanges.
> Unless we invent a new wiki-syntax they will remain broken.
> 
> /Arno

Ahhh.. that was the problem with my diff links.  I hadn't had a chance
to look into them, and it didn't click that the break might be related
to that change.
Instead of
	   $ServerAddress = "";
use
	   $ServerAddress = "http:";

That has the same effect of using relatvie URI's, doesn't break the
diff links in RecentChanges

NeilBrown

Re: [Phpwiki-talk] misc pending patches / restructuring

[Steve W. <sw...@wc...>]

On Mon, 9 Oct 2000, Arno Hollosi wrote:

> 
> Nested DefinitionLists by Neil Brown:
> Looks ok.
> Note: this still relies on tabs. I think we should get rid of tabs ASAP.

When I added tabless syntax, I skipped term/defs because there was no
clear solution, and nobody uses them (even on c2.com, and in regular HTML
pages). Ward probably coded them in in 1995 when people were still
exploring HTML and might have used them. Anyhow, I will take a look at
that too tonight. There should be a simple syntactic solution.
 
> SearchType patch by Neil Brown:
> The actual patch is ok. If a search box should be included in the default 
> browse.html should be discussed.

I'm leary of adding much to browse.html. I have played with it quite a bit
and never liked additions. Jakob Neilsen (useit.com) recommends that the
logo be in the upper left and link to the home page, and the search box be
in the upper right (based on convention and usability studies.) I haven't
worked out a layout like that yet.

Search should be redesigned as well; page title searches are somewhat
unconventional (then again, so are Wikis) and there is no sophistication
to the full text search... but then I may be speculating about gold
plating, and PhpWiki does well where it's simple. I will go into more
detail on this at at later date.

> Email notification of page changes by Jochen Causemann:
> Jochen's solution has some merits, but drawbacks as well. In his patch email 
> addresses are stored in the WikiPage themselves. This means that not only are 
> these email addresses public, but anyone can remove other's addresses by 
> editing the page. 

and worse, adding other people's emails...

> I opt for the PyWiki approach, in which addresses are 
> stored outside the document. Also, I'd like to have the option to either 
> receive wiki-markup or html emails. And (for those wiki addicts): the 
> possibility to subscribe to all pages / or given sets of pages.
> I think we should hold off this feature for some more time.. First we should 
> get other things in order, then add user-management (which will also include 
> email notification).

Agreed; would you object to including the patch but leaving it disabled by
default? Wikis on intranets would not face malicious user problems (in
theory ;-)
 
> I think the next thing we should do is clean up the db interface (borrow the 
> good stuff from Jeff's branch) and integrate Jan's localization patch. Wrt 
> Jan's patch the open question is still how we should deal with templates. I'm 
> not convinced yet, that turning the templates into php files is a good thing.

I have to extract Jeff's branch again and recommit it... CVS removes a
file for all branches, so as it is right now you cannot really check out
Jeff's copy. It will just require some magic CVS incantations.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] misc pending patches / restructuring

[Arno H. <aho...@in...>]

Nested DefinitionLists by Neil Brown:
Looks ok.
Note: this still relies on tabs. I think we should get rid of tabs ASAP.

SearchType patch by Neil Brown:
The actual patch is ok. If a search box should be included in the default 
browse.html should be discussed.

Email notification of page changes by Jochen Causemann:
Jochen's solution has some merits, but drawbacks as well. In his patch email 
addresses are stored in the WikiPage themselves. This means that not only are 
these email addresses public, but anyone can remove other's addresses by 
editing the page. I opt for the PyWiki approach, in which addresses are 
stored outside the document. Also, I'd like to have the option to either 
receive wiki-markup or html emails. And (for those wiki addicts): the 
possibility to subscribe to all pages / or given sets of pages.
I think we should hold off this feature for some more time. First we should 
get other things in order, then add user-management (which will also include 
email notification).


About the lib/ and image/ changes:
No objections here. I checked a clean install from latest CVS with mySQL and 
it worked ok.

I think the next thing we should do is clean up the db interface (borrow the 
good stuff from Jeff's branch) and integrate Jan's localization patch. Wrt 
Jan's patch the open question is still how we should deal with templates. I'm 
not convinced yet, that turning the templates into php files is a good thing.

/Arno

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Steve W. <sw...@pa...>]

I'll fix it when I get home tonight...

sw

On Mon, 9 Oct 2000, Arno Hollosi wrote:

> Steve,
> 
> > This patch sounds like a good idea: no default server name. Another "why
> > didn't I think of that?" idea. Anybody see any holes in it?
> 
> this breaks the diff links in RecentChanges.
> Unless we invent a new wiki-syntax they will remain broken.
> 
> /Arno
> 

http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Arno H. <aho...@in...>]

Steve,

> This patch sounds like a good idea: no default server name. Another "why
> didn't I think of that?" idea. Anybody see any holes in it?

this breaks the diff links in RecentChanges.
Unless we invent a new wiki-syntax they will remain broken.

/Arno

[Phpwiki-talk] images moved

[Steve W. <sw...@wc...>]

... to a new subdirectory, images/ and lib/config.php has been updated to
match.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] project restructuring

[Steve W. <sw...@wc...>]

I've moved all wiki_*.php3 files to lib/*.php. I've also renamed
index.php3 to index.php. I haven't touched admin/ yet though, and a couple
other files (test_dbmlib.php3).

I've gone though the INSTALL and README files, and some of the default
pages as well hunting down occurances of *php3 and updating them.


CVS moves "removed" files to the "attic" and you can see the log files for
the wiki_*.php3 files here:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/phpwiki/Attic/?cvsroot=phpwiki&sortby=date

(the lib/*php files start with new logs, since CVS does not have a good
mechanism for renaming the files, this was the best way).

To update your private CVS tree, be sure to do:

cvs update -d -P

-d will add new directories 
-P will prune empty directories

I think both get new pages/delete old pages as well.

So far I've tested the new setup from a clean checkout of the sources, on
DBM and Postgresql, and it looks good. On a stock RedHat box, I had to
edit the httpd.conf so Apache recognizes .php as well as php3 (the
default). I think the new builds of Apache have .php already.

flame me as needed
sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] Cutover from wiki_*php3 to lib/*.php

[Steve W. <sw...@wc...>]

Tomorrow I am going to make some filename changes:

All wiki_*php3 files will live in lib/*.php. This was discussed on the
list months ago, and can provide for better security *if* the admin blocks
browser access to the directory. I found that naming the files *.inc
allows browsers to see the plain text of the files, and that's a little
too "open source" for my comfort. As .php files they are executed, as they
would be now as wiki_*php3, but the source cannot be viewed.

index.php3 will become index.php; this is for consistency, bringing the
project "up to date" and to please the several requests I've gotten for
this.

Voice objections/criticisms by then, or request a delay if you don't have
time to make one.

cheers
sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] [Fwd: Mail-distribution-list for Wiki]

[Steve W. <sw...@pa...>]

-- 
http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

[Phpwiki-talk] [Fwd: Mail-distribution-list for Wiki]

[Steve W. <sw...@pa...>]

The idea of subscribing to a page for change notifications has been
implemented in other Wikis, PyWiki being one of them...

sw


-- 
http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

[Phpwiki-talk] PATCH - search from each page.

[Neil B. <ne...@cs...>]

Another patch for phpwiki.

I like to be able to have a search form on each browser page (instead
of having to go to a special search page.
You can currently do this by customising browse.html.
However you either have to choose beteen titlesearch and fullsearch,
which is restruictive, or have two entry fields, which is noisy.

The following patch allows you to have submit buttons (or even an
option menu) that select which type of search by setting $searchtype,
and provides a sample usage in browse.html

NeilBrown



--- ./templates/browse.html	2000/10/06 02:38:48	1.1
+++ ./templates/browse.html	2000/10/06 02:45:57	1.3
@@ -19,6 +19,12 @@
 [<a href="###SCRIPTURL###?diff=###PAGEURL###">diff</a>])
 <br>
 <a href="###SCRIPTURL###?FindPage">FindPage</a> by browsing or searching
+<form action="###SCRIPTURL###">
+Search:
+<input type='text' size=40 name=searchstring>
+<input type=submit value=search name=searchtype>
+<input type=submit value=full name=searchtype>
+</form>
 <hr noshade>
 <small>###RELATEDPAGES###</small>
 
--- ./index.php3	2000/10/06 02:21:24	1.1
+++ ./index.php3	2000/10/06 02:45:21	1.2
@@ -13,6 +13,15 @@
    $dbi = OpenDataBase($WikiPageStore);
 
 
+   // To allow choice of submit buttons to determine type of search:
+   if ($searchtype == "search") {
+	$search = $searchstring;
+   } else if ($searchtype == "full") {
+	$full = $searchstring; 
+   } else if ($searchstring) {
+	// default to plain search
+	$search = $searchstring;
+   }
 
    if ($edit) {
       $admin_edit = 0;

[Phpwiki-talk] PATCH - nested DefinitionLists

[Neil B. <ne...@cs...>]

Steve,
 here is another patch, which I am cc:ing to phpwiki-talk (I hope that
 is not inappropriate).

 It allows DefinitionLists to be nested in the same what at Orders and
 Unordered Lists can be.

 I really wanted this for 
    http://kernelbook.sourceforge.net:80/wiki/?DentryStructure
 (see the definition of d_flags)
 so I thought I would try to make sure that it is available in the
 next version.

NeilBrown


--- ./wiki_transform.php3	2000/10/06 02:21:24	1.1
+++ ./wiki_transform.php3	2000/10/06 02:25:45	1.2
@@ -200,9 +200,10 @@
       }
 
       // HTML modes: pre, unordered/ordered lists, term/def
-      if (preg_match("/(^\t)(.*?)(:\t)(.*$)/", $tmpline, $matches)) {
+      if (preg_match("/(^\t+)(.*?)(:\t)(.*$)/", $tmpline, $matches)) {
          // this is a dictionary list item
-         $html .= SetHTMLOutputMode("dl", SINGLE_DEPTH, 1);
+         $numtabs = strlen($matches[1]);
+         $html .= SetHTMLOutputMode("dl", SINGLE_DEPTH, $numtabs);
          $tmpline = "<dt>" . $matches[2] . "<dd>" . $matches[4];
 
       // oops, the \d needed to be \d+, thanks al...@mi...

[Phpwiki-talk] Wiki (fwd)

[Steve W. <sw...@pa...>]

Another customized PhpWiki.

http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

---------- Forwarded message ----------
Date: Mon, 02 Oct 2000 08:11:57 +0200
From: Thomas Hoog <th...@4h...>
To: sw...@pa...
Subject: Wiki

Hi Steve

I have set up a wiki on http://www.4high.com

I made some changes.

The wiki is categorized and you must login before updating anything
and browsing any *Privat*. Anything marked *Public* could be changed
by anybody.

/Thomas Höög (high in english)
mailto:th...@4h...

[Phpwiki-talk] phpwiki - I like it. (fwd)

[Steve W. <sw...@pa...>]

This patch sounds like a good idea: no default server name. Another "why
didn't I think of that?" idea. Anybody see any holes in it?

sw

http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun


---------- Forwarded message ----------
Date: Fri, 6 Oct 2000 14:16:52 +1100 (EST)
From: Neil Brown <ne...@cs...>
To: Steve Wainstead <Wai...@us...>
Subject: phpwiki - I like it.



hi,
 I was introduced to phpwiki recently through
   http://kernelbook.sourceforge.net/wiki/KernelWiki
 and I like it.
 I tried building something vaguely similar a while back, but made the
 mistake of over designing, and it never quite got off the ground.
 phpwiki looks like a much better starting point.

 I have been playing with if for all of a day and a half now and have
 a few changes I would like to suggest.  So, you can expect to
 received a few patches in the mail from me.  I hope that's ok.

 My first patch addresses the setting of ServerAddress.
 I have found that the best value for ServerAddress (for me) is an
 empty string.  This causes relative URI's to appear in the html which
 browsers cope with quite well.  I need this because I am running it
 from a web server on my note book (for testing) and often I don't
 have an internet address and haveto use localhost.   But if I set
 ServerAddress to be localhost, then when I am plugged in, I cannot
 access the pages from else where.

 This should work out-of-the-box for everybody.  I cannot think of a
 case when specifing a server address is needed, but there might be one.

 The following patch makes empty string the default, but still leave
 the other possibilities as options.
 I also needed to removed ServerAddress from SignatureImg (in line wit
 $logo) so that it is used as a relative URI too.

NeilBrown

 


--- ./wiki_config.php3	2000/10/06 02:21:24	1.1
+++ ./wiki_config.php3	2000/10/06 02:23:24	1.2
@@ -13,19 +13,21 @@
       can just give the URL without the script name.
    */
 
-   // You should set the $ServerAddress below, and comment out
-   // the if/else that follows. The if/else sets the server address
-   // dynamically, and you can save some cycles on the server by
-   // setting $ServerAddress yourself.
+   // An empty server address:
+   $ServerAddress = "";
+   // works quite well thanks to relative URIs.  If find that you 
+   // want an explicit address, you can set one yourself by changing 
+   // and uncommenting:
    //$ServerAddress = "http://127.0.0.1:8080/phpwiki/";
-
-
+   // Or you could use the if/else statement below to deduce
+   // the $ServerAddress dynamically.
+   /*
    if (preg_match("#(.*?)([^/]*$)#", $REQUEST_URI, $matches)) {
       $ServerAddress = "http://$SERVER_NAME:$SERVER_PORT" . $matches[1];
    } else {
       $ServerAddress = "http://$SERVER_NAME:$SERVER_PORT$REQUEST_URI";
    }
-
+   */
    // if you are using MySQL instead of a DBM to store your
    // Wiki pages, use wiki_mysql.php3 instead of wiki_dbmlib.php3
    // See INSTALL.mysql for details on using MySQL
@@ -138,7 +140,7 @@
 	"MESSAGE" =>   "templates/message.html"
 	);
 
-   $SignatureImg = "$ServerAddress/signature.png";
+   $SignatureImg = "signature.png";
    $logo = "wikibase.png";
 
    // date & time formats used to display modification times, etc.

Re: [Phpwiki-talk] Patch: internationalisation with php3 fallback [Was: ...]

[Jan N. <ja...@gn...>]

On Sunday, 1 October 2000, Steve Wainstead writes:

> Yes, it's been on my mind for a while but haven't gotten around to it. The
> section the admin edits could be shortened and made a lot clearer.

Ok.

> Do you volunteer? ;-)

Maybe I'll make a debian package, but I don't have the time to
adopt packages for debian.  If you want a redhat package you'll
have to ask me real nice, because I don't have use for that
myself :-)

Jan.

-- 
Jan Nieuwenhuizen <ja...@gn...> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

[Phpwiki-talk] Re: Patch: internationalisation with php3 fallback [Was: ...]

[Jan N. <ja...@gn...>]

On Monday, 2 October 2000, Arno Hollosi writes:

> Hm, yes. I'm still not 100% convinced but could accept it in its dual form 
> (mo + php3). Btw, you didn't localize all strings yet. E.g. wiki_search is 
> missing.

Yes, I wanted to see first if this got in.  I'll see to the remaining
strings and pages.

> Hm, that would mean making php files out of the templates?

Yes, it's a trade-off.  Maybe just do a gettext () on the template

      $page = gettext (join('', file($templates[$template])));

(doesn't make sense on a per line basis, I guess?  Then we'd have
only the pgrsrc as extra, which would be quite accepteble.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <ja...@gn...> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

[Phpwiki-talk] Re: Patch: internationalisation with php3 fallback [Was: ...]

[Arno H. <aho...@in...>]

>Ok, that's a valid reason.  A reason to use gettext tools would be
>that you could have them translated by the GNU translation project.
>However, maybe that's all a bit overdone, because there are so few
>strings in php code...

Hm, yes. I'm still not 100% convinced but could accept it in its dual form 
(mo + php3). Btw, you didn't localize all strings yet. E.g. wiki_search is 
missing.


>> On a side note: I think all files for translators should be moved into
>> a "translator" directory: currently that is translate.sh and the files in
>> the po directory. That way one can easily delete stuff unnecessary for
>> running the wiki.
>
>Otoh, it's non standard, so people might wonder how it all works.

I think you misunderstood. It would still be in the tarball, but users could
then more easily delete files not necessary for a running wiki.

>It would be good if the templates were gettextised too, so that there'd
>only be the .po's and the pgsrc's.

Hm, that would mean making php files out of the templates?
The nice thing right now is that GeneratePage() produces the entire page in 
one string. php-templates would make this more complicated.
Or is there a way around this?


/Arno

p.s. I'm again gone for some days - so don't expect immediate replies to 
further emails.

Re: [Phpwiki-talk] Patch: internationalisation with php3 fallback [Was: ...]

[Steve W. <sw...@wc...>]

On Sun, 1 Oct 2000, Jan Nieuwenhuizen wrote:

> Ok.  Wouldn't it help if we made wiki_config.php3 a lot smaller,
> and make type of database selectable by a single variable, something
> like:
> 
>     <?php3
> 
>        $DataBase = "dbm";  #  "mysql", "pgsql", "msql"
> 
>        $DatabaseDir = "/tmp";   # only used by DBM
>        $DatabaseName = "wiki";  # only used by 
>        $DatabaseUser = "wiki";
>        $DatabasePass = "";
>        $LANG = "C";
> 
> 
>        // you probably don't need to change these
>        $DatabaseServer = "localhost";
>        $DatabasePort = "5432";  # only used by pgsql
>        ...
> 
>      ?>
> 
> This gets included  by index.php3, which also includes the relevant
> db config.

Yes, it's been on my mind for a while but haven't gotten around to it. The
section the admin edits could be shortened and made a lot clearer.
 
> Also, why don't we make RedHat and debian packages.  That should make
> install both easy, and OK for no-messing-with-my-package-system people.
> 
>     apt-get install phpwiki
> 
> is a lot simpler than surfing the internet for a wiki's most recent
> tarball, handconfigure it, etc.


Do you volunteer? ;-)

sw


...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] Re: Patch: internationalisation with php3 fallback [Was: ...]

[Jan N. <ja...@gn...>]

On Sunday, 1 October 2000, Arno Hollosi writes:

> So I installed the gettext package and your script runs ok now.
> Ok, maybe we should use gettext to automatically produce files
> for the translators. But I would still use hash-tables for phpwiki
> (generated automatically from those .po files if you like).
>
> Apart from avoiding duplicate information (.mo and .php3 files) and being 

Ok, that's a valid reason.  A reason to use gettext tools would be
that you could have them translated by the GNU translation project.
However, maybe that's all a bit overdone, because there are so few
strings in php code...

> How can you have per-visitor localization?

 [snip -- would be real cool]

> Or is this feature too far off the mark?

Yes, I pondered about that too, esp. wrt to the RecentChanges page.
I don't think it would be worth the effor: you'd get 'EditText'
instead of 'VeranderText' when you visit a dutch wiki, but all
pages would still be in dutch.  I think localisation on a per-wiki
basis would be ok.

> On a side note: I think all files for translators should be moved into
> a "translator" directory: currently that is translate.sh and the files in the
    +  
> po directory. That way one can easily delete stuff unnecessary for running 
> the wiki.

Otoh, it's non standard, so people might wonder how it all works.

> And I don't understand why we need wiki_linguas.php3. Either the pagename 

Duh.  I think that I goofed on that one.  It's probably that I kept
seeing things like EditText, before I translated the templates.
It would be good if the templates were gettextised too, so that there'd
only be the .po's and the pgsrc's.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <ja...@gn...> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: [Phpwiki-talk] Patch: internationalisation with php3 fallback [Was: ...]

[Jan N. <ja...@gn...>]

On Sunday, 1 October 2000, Steve Wainstead writes:

> The patch files were over 40K, which made the listserv hold them for
> approval. I upped the msg size limit to 100K.

Ok, didn't know/check it was so big already.

> I'm siding with Arno on the ease of installation issue, which has been a
> major concern of mine since version 0.01 back in December. It should be as
> easy as tar -xzvf <phpwiki tarball> and it runs on any GNU/Linux or BSD
> system.

Sure, if you think that's needed.  Arno had a simple (=good) idea that
I stole so that my last patch will allow this, although only php4 user
get the ``better'' implementation.  The legacy php3 support can later
be dropped at any time.

> When we say "users" of PhpWiki we usually mean "the people who install and
> maintain the Wiki," i.e. the sysadmins and programmers. It's my belief
> that the easier it is to use (install) the more readily accepted it is;

Ok.  Wouldn't it help if we made wiki_config.php3 a lot smaller,
and make type of database selectable by a single variable, something
like:

    <?php3

       $DataBase = "dbm";  #  "mysql", "pgsql", "msql"

       $DatabaseDir = "/tmp";   # only used by DBM
       $DatabaseName = "wiki";  # only used by 
       $DatabaseUser = "wiki";
       $DatabasePass = "";
       $LANG = "C";


       // you probably don't need to change these
       $DatabaseServer = "localhost";
       $DatabasePort = "5432";  # only used by pgsql
       ...

     ?>

This gets included  by index.php3, which also includes the relevant
db config.

Also, why don't we make RedHat and debian packages.  That should make
install both easy, and OK for no-messing-with-my-package-system people.

    apt-get install phpwiki

is a lot simpler than surfing the internet for a wiki's most recent
tarball, handconfigure it, etc.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <ja...@gn...> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

[Phpwiki-talk] Re: Patch: internationalisation with php3 fallback [Was: ...]

[Arno H. <aho...@in...>]

> Hmm.  Now that I write this down, we can have both.  We should
> definately use the gettext tools for the translators.  They produce
> the .po files, and it would be a shame not to use the built-in
> localisation mechanism for php4.
> But maybe we can easily provide a fallback for php3 users:
> and use a script to generate the fallback $locale table from
> the .po file.

So I installed the gettext package and your script runs ok now.
Ok, maybe we should use gettext to automatically produce files
for the translators. But I would still use hash-tables for phpwiki
(generated automatically from those .po files if you like).

Apart from avoiding duplicate information (.mo and .php3 files) and being 
usable by php3 users, it has the cons of both approaches, plus another one:

How can you have per-visitor localization?
Say, e.g. the wiki is dutch, but I want to see the edit-page in English.
This should easily be possible, by detecing the LANG of the visitor and using
that one for templates etc. Of course, the content of the page doesn't change.

Problem: our WikiPageNames are localized as well, i.e. if I would simply 
switch from NL to US phpwiki would install the "FrontPage" page, as it 
doesn't exist in a Dutch wiki.

Therefore phpwiki would have to distinguish between two languages: the 
visitor's language and the base wiki language. A modified gettext call could 
take a second argument in order to tell which language to use (base for 
pagenames, visitor for everything else). The php-gettext doesn't allow 
per-call setting of the language, does it?

Or is this feature too far off the mark?

On a side note: I think all files for translators should be moved into
a "translator" directory: currently that is translate.sh and the files in the 
po directory. That way one can easily delete stuff unnecessary for running 
the wiki.

And I don't understand why we need wiki_linguas.php3. Either the pagename 
occurs somwhere and that usage is localized or it doesn't occur and there's 
no need to include it in a file like wiki_linguas. Can you give me an example 
of where wiki_linguas is necessary?

/Arno