phpwiki-talk

Re: [Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

On Fri, 8 Jun 2001, Jeff Dairiki wrote:

> PhpWiki specifies the charset in a <meta http-equiv> tag
> in the HTML headers on each and every page:
>
>   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
>
> As you note, the charset currently is not specified in the HTTP headers.
> If that is causing problems with some browsers (is it?), that's easy enough
> to fix (we should probably fix that anyway).

It doesn't break any browser that _looks for_ Content-Type _and_ supports
Latin-1, which probably makes this a non-issue. There could be browsers
that ignore the META tags and thus need the HTTP headers, but since META
is defined in everything since HTML2.0 I deem these browsers as broken.
Your point is taken.

> I suppose entitizing upon output as you suggest doesn't hurt anything,
> but it still seems unnecessary to me.

Apparently (and to me, surprisingly), you're right (as far as you set
Content-Type, which we do). It's probably just one of those pedanticisms
you acquire over time. :-)

> (I know there have been many requests for multi-byte character support,
> but that's not an easy fix.   I think that pretty much requires switching
> to using unicode/UTF-8 internally, and this won't be practical without
> unicode support compiled into PHP and its regexp libraries.)

And the database, if it does string matching, additionally (using LIKE, ~
and whatnot).

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] PHPWiki accent support

[Jeff D. <da...@da...>]

>Does & still have to be a magic character if it is only generated on
output? I am not advocating writing (entering data in the form) entitized
>-- this is broken and counter-productive; only displaying entitized, to
>allow a wider audience with less breakage. This is _almost_ a non-issue
>with Latin-1, since most browsers render that by default, but on
>non-Latin-1 charsets (and thus, locales and languages), this _will_ be an
>issue. Is this besides the point?

Okay, I see that perhaps I misunderstood your initial suggestion.

Stock PhpWiki really only supports ISO-8859-1.  (Though I suppose
it would be easy enough to hack it to support any other single
eight-bit character set.)

PhpWiki specifies the charset in a <meta http-equiv> tag
in the HTML headers on each and every page:

  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

As you note, the charset currently is not specified in the HTTP headers.
If that is causing problems with some browsers (is it?), that's easy enough
to fix (we should probably fix that anyway).

I suppose entitizing upon output as you suggest doesn't hurt anything,
but it still seems unnecessary to me.

Is anyone using PhpWiki with any other non ISO-8859-1 eight-bit charset?

(I know there have been many requests for multi-byte character support,
but that's not an easy fix.   I think that pretty much requires switching
to using unicode/UTF-8 internally, and this won't be practical without
unicode support compiled into PHP and its regexp libraries.)

Re: [Phpwiki-talk] gettext problems

[Sergio A. K. <ser...@ho...>]

----- Original Message ----- 
From: "Jeff Dairiki" <da...@da...>

hi jeff,

> >I agree 100% with you, while I can see the point on using gettext with
> >a languaje like C, I still cannot see the point on using gettext on
> >a languaje like PHP.
> 
> Not that I'm completely sold on gettext either, but one big advantage
> of using gettext (particularly for developers/translators who use emacs)
> is the ability to use the GNU gettext tools to do things like
> find new strings to be translated in (changed) source code, and
> merge those new strings into the translation (.po) files.

this can be done with a simple perl script I suppose...

> Note that PhpWiki _should_ (is designed to) work even if
> PHP was compiled without gettext support.  If it doesn't, that's
> a bug.  Report it.

well, the fact is, I do have php with gettext support,
but with the recent gettext changes, php changes and so on
I ended up with a semi-working gettext support in php

and I reported my problem to nalin at redhat who confirmed
the problem...

and the fact is that a dictionary-based translation Just Work (tm),
translations with gettext, work if you are lucky...

> >a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
> >(ie. the client browser languaje) ... is IMO better ...
> 
> 
> 1. You wouldn't want HTTP_ACCEPT_LANGUAGE to affect the default
>    pgsrc.
> 
> 2. Since the page content of a particular wiki are (most often)
>    primarily in one language, there's not a whole lot of point
>    in allowing the viewer to select various languages for the
>    templates/dates...

yeah, that may be a problem, but the root problem is that there are
different templates for every languaje, and *that* is what is wrong
IMHO...
and another thing that is wrong is that phpWiki treat english like
a special languaje, there is no need to, "en" should be in locale
like everybody else...

/sergio

Re: [Phpwiki-talk] PHPWiki accent support

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

On Fri, 8 Jun 2001, Jeff Dairiki wrote:

> One cheap solution which might help a few people would be to add a
> line containing the funky characters to the editpage.html form.
> That way, people who can't figure out how to type in an accented
> character could at least cut and paste the one they want.

This is a neat idea... although most people who use accented/umlatted/etc
chars probably have them on their keyboard. I had to use a French keyboard
once and it blew my mind.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

RE: [Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

(I hate not being subscribed to a list. Fixing that..)

Jeff writes:

	Yes, but you can type them in as ISO-8859-1 eight-bit characters
	just fine.  (What you have to do to type these in depends on your
	OS & browser &c.)

	Do we want to support entities in the page text?  If we do then
	'&' suddenly becomes a magic character.  (I vote against it.)

Hey Jeff, thanks for the answer.

Now that's a good question. By using non-entitized characters that are
supported in Latin-1 (aka ISO-8859-1) and other character sets, you do
create a problem of backwards compatibility with browsers that have no
support for selecting (or discovering, if the standard indication
Content-Type: text/html; charset=foobar is used) character sets.

This might and might not be an issue depending on the specifics of your
application, but the truth is that very few sites today issue
Content-type: lines that specify the correct charset, and international
browsers do break (I've seen this over in Asia, and so do we when visiting
Japanese sites in Netscape).

Now using entities makes this very simple (which is why I've done the
conversion here, myself) and avoids any sort of encoding problem. I don't
understand the point that & suddenly becomes a magic character -- why?
(Perhaps more importantly; what is a magic character?). If this means it
has to be allowed inside the regexp, for example, I disagree, though
perhaps I'm viewing this incompletely:

I only do entitizing on HTML output; internally, they are stored as
Latin-1 characters (actually, whatever you specify your browser and
database to handle AFAICS) and they are converted inside transform.php,
which makes all internal handling treat Latin-1. I can't see at this point
how this affects other character sets, but perhaps this is an alternative
view from yours?

Does & still have to be a magic character if it is only generated on
output? I am not advocating writing (entering data in the form) entitized
-- this is broken and counter-productive; only displaying entitized, to
allow a wider audience with less breakage. This is _almost_ a non-issue
with Latin-1, since most browsers render that by default, but on
non-Latin-1 charsets (and thus, locales and languages), this _will_ be an
issue. Is this besides the point?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] etc/*

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

This is something that's been on my mind since Jeff moved all the config
into index.php and all the main functionality into main.php.

I think this is the old argument about where does main() go: at the top,
in the first file, or at the bottom after you've declared everything? I
miss having index.php contain all the main functionality (the program
flow) and all config info off in a config file.

Sergio is following a standard practice of putting config info in etc/,
and that's admirable. I would argue that PhpWiki is small enough that
it's not necessary, but it couldn't hurt to have lib, etc, var or whatever
is needed. An etc/ could hold a config file and a style sheet.

~swain

On Fri, 8 Jun 2001, Sergio A. Kessler wrote:

> ----- Original Message -----
> From: "Jeff Dairiki" <da...@da...>
>
>
> > >putting the code where my mouth is, this patch create
> > >a etc/* directory to put cfg there, so cleaning up index.php
> > >
> > >comments ?
> >
> > All you've done is split index.php into four separate files.
> > What does this buy you?
>
> some cleanup, IMO having the cfg in index.php, and even worse
> when you put all cfg in there, all togheter...
>
> well, maybe is my coding style, I prefer to have ten files
> which do ten differents things, and not one file that does
> ten differents things...
>
> /sergio
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] etc/*

[Sergio A. K. <ser...@ho...>]

----- Original Message ----- 
From: "Jeff Dairiki" <da...@da...>


> >putting the code where my mouth is, this patch create
> >a etc/* directory to put cfg there, so cleaning up index.php
> >
> >comments ?
> 
> All you've done is split index.php into four separate files.
> What does this buy you?

some cleanup, IMO having the cfg in index.php, and even worse
when you put all cfg in there, all togheter...

well, maybe is my coding style, I prefer to have ten files
which do ten differents things, and not one file that does
ten differents things...

/sergio

Re: [Phpwiki-talk] gettext problems

[Jeff D. <da...@da...>]

>I agree 100% with you, while I can see the point on using gettext with
>a languaje like C, I still cannot see the point on using gettext on
>a languaje like PHP.

Not that I'm completely sold on gettext either, but one big advantage
of using gettext (particularly for developers/translators who use emacs)
is the ability to use the GNU gettext tools to do things like
find new strings to be translated in (changed) source code, and
merge those new strings into the translation (.po) files.

Note that PhpWiki _should_ (is designed to) work even if
PHP was compiled without gettext support.  If it doesn't, that's
a bug.  Report it.

>a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
>(ie. the client browser languaje) ... is IMO better ...


1. You wouldn't want HTTP_ACCEPT_LANGUAGE to affect the default
   pgsrc.

2. Since the page content of a particular wiki are (most often)
   primarily in one language, there's not a whole lot of point
   in allowing the viewer to select various languages for the
   templates/dates...

(see also
  <http://phpwiki.sourceforge.net/phpwiki/index.php?MultiLingualWiki>)


  
  

Re: [Phpwiki-talk] etc/*

[Jeff D. <da...@da...>]

>putting the code where my mouth is, this patch create
>a etc/* directory to put cfg there, so cleaning up index.php
>
>comments ?

All you've done is split index.php into four separate files.
What does this buy you?

Re: [Phpwiki-talk] PHPWiki accent support

[Jeff D. <da...@da...>]

Thank you for the comments Christian,

>I'm quite new to PHPWiki and not at all familiar with it, but I've noticed
>that at least in the default configuration there is no support for
>entitized accents (=C1 becoming Ã) as we commonly use in non-english
>countries.

Yes, but you can type them in as ISO-8859-1 eight-bit characters 
just fine.  (What you have to do to type these in depends on your
OS & browser &c.)

Do we want to support entities in the page text?  If we do then
'&' suddenly becomes a magic character.  (I vote against it.)

One cheap solution which might help a few people would be to add a
line containing the funky characters to the editpage.html form.
That way, people who can't figure out how to type in an accented
character could at least cut and paste the one they want.

>In my case, I've ... changed WikiNameRegexp to allow accents
>in the link names.

This has been done in the development branch.

It probably won't be done in the stable branch, since that would
change the semantics of existing wikis.  (I suppose the alternative
WikiNameRegexp could be added in a comment, though.)

See also:
 http://phpwiki.sourceforge.net/phpwiki/index.php?WikiNameRegexp

Jeff

[Phpwiki-talk] nightly builds up again

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

I just noticed the crontab is back on my account at sourceforge, and the
nightly tarball is being made again.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

Hey there,

I'm quite new to PHPWiki and not at all familiar with it, but I've noticed
that at least in the default configuration there is no support for
entitized accents (=C1 becoming Ã) as we commonly use in non-english
countries. In my case, I've hacked transform.php to provide for the
changes and also changed WikiNameRegexp to allow accents in the link
names.

Now a better way to do this would be to flat-out run text through
htmlentities() but I haven't seen the proper way to do this (how to match
on words and _then_ get then changed with htmlentities..) I've attached
the (kind of stupid) fixes I've made in the hope someone else wanting
something that works is helped.

Anyone having this sort of trouble? Spanish-speakers? Is this already
accounted for?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] ADODB

[Sergio A. K. <ser...@ho...>]

the "official" db abstraction layer for php is DB (from PEAR)
http://pear.php.net
DB is developed by Stig Baken (a long time php hacker)
DB is being distributed with php > 4

I'm working rigth now with DB, so far:
advantages: simple, clean design, ligthweigth, come with distros
disadvantages: WIP

last time I looked at ADODB, it seemed (to me) overdesigned,
complex and bloated, but I could be wrong.

/sergio

----- Original Message -----
From: "Steve Wainstead" <sw...@pa...>


>
> This looks like something similar to the Perl DBI, which PHP has needed
> for some time... isn't there another project, PHPLib, or something like
> that? This is the first project I've seen that isn't beta, btw.
>
> thanks Reini!
> ~swain
>
> On Thu, 7 Jun 2001, Reini Urban wrote:
>
> > Has anybody looked at this yet?
> > http://freshmeat.net/projects/adodb/
> >
> > ADODB is a set of advanced PHP database wrapper classes. It supports
MySQL,
> > PostgreSQL, Interbase, Oracle, MS SQL 7, Sybase,  DB2, FrontBase,
Foxpro,
> > Access, ADO, and generic ODBC. A metatype system is built in, making it
> > possible to figure out that types such  as CHAR, TEXT, and STRING are
> > equivalent in different databases. It also features an SQL to HTML popup
> > menu and SQL to HTML table support and recordset caching.
> >
> > This seems to solve some of our DB problems. Wouldn't it be easier to
use
> > such an external classlib?
> >
> >
> > _______________________________________________
> > Phpwiki-talk mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> >
>
> ---
>                   http://www.panix.com/~swain/
> "Without music to decorate it, time is just a bunch of boring
> production deadlines or dates by which bills must be paid."
>                      -- Frank Zappa
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] ADODB

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

This looks like something similar to the Perl DBI, which PHP has needed
for some time... isn't there another project, PHPLib, or something like
that? This is the first project I've seen that isn't beta, btw.

thanks Reini!
~swain

On Thu, 7 Jun 2001, Reini Urban wrote:

> Has anybody looked at this yet?
> http://freshmeat.net/projects/adodb/
>
> ADODB is a set of advanced PHP database wrapper classes. It supports MySQL,
> PostgreSQL, Interbase, Oracle, MS SQL 7, Sybase,  DB2, FrontBase, Foxpro,
> Access, ADO, and generic ODBC. A metatype system is built in, making it
> possible to figure out that types such  as CHAR, TEXT, and STRING are
> equivalent in different databases. It also features an SQL to HTML popup
> menu and SQL to HTML table support and recordset caching.
>
> This seems to solve some of our DB problems. Wouldn't it be easier to use
> such an external classlib?
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] ADODB

[Reini U. <ru...@xa...>]

Has anybody looked at this yet?
http://freshmeat.net/projects/adodb/

ADODB is a set of advanced PHP database wrapper classes. It supports MySQL,
PostgreSQL, Interbase, Oracle, MS SQL 7, Sybase,  DB2, FrontBase, Foxpro,
Access, ADO, and generic ODBC. A metatype system is built in, making it
possible to figure out that types such  as CHAR, TEXT, and STRING are
equivalent in different databases. It also features an SQL to HTML popup
menu and SQL to HTML table support and recordset caching.

This seems to solve some of our DB problems. Wouldn't it be easier to use
such an external classlib?

RE: [Phpwiki-talk] gettext problems

[Pablo R. R. <pr...@cl...>]

Sergio,

> while I can see the point on using gettext with
> a languaje like C, I still cannot see the point on using gettext on
> a languaje like PHP.

:)

> a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
> (ie. the client browser languaje) and a simple dictionary,
> is IMO better (and more simpler for translators)

Yes, or like phpnuke or phpbb does, defining variables for lang

> anyway, I get 1.2.0 to work with my locale using "es_AR" with
> this simple patch
> 
>       putenv ("LANG=$LANG");
> +      if ( setlocale('LC_ALL', "") == null)
> +        echo "INVALID locale";
>       bindtextdomain ("phpwiki", "./locale");

Cool! I'll try this.

Saludos,

Pablo Roca

Re: [Phpwiki-talk] gettext problems

[Sergio A. K. <ser...@ho...>]

hi pablo,

I agree 100% with you, while I can see the point on using gettext with
a languaje like C, I still cannot see the point on using gettext on
a languaje like PHP.

a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
(ie. the client browser languaje) and a simple dictionary,
is IMO better (and more simpler for translators)

anyway, I get 1.2.0 to work with my locale using "es_AR" with
this simple patch

      putenv ("LANG=$LANG");
+      if ( setlocale('LC_ALL', "") == null)
+        echo "INVALID locale";
      bindtextdomain ("phpwiki", "./locale");

now, I don't know what to do with my changes, I'm just waiting
for mantainers feedback...

/sergio

----- Original Message ----- 
From: "Pablo Roca Rozas" <pr...@cl...>


> Hi Sergio,
> 
> I wa the man who did the spanish traslation according with the supplied
> instructions and some help from here.
> 
> Unluckyly, I can't put this to work in my site cause they don't allow
> the gettext, maybe I can check this with another ISP. But I don't feel
> comfortable with gettext oriented funcs, cause some ISP's don't use it.
> 
> Imagine how I feel .. :)
> 
> Pablo Roca

RE: [Phpwiki-talk] gettext problems

[Pablo R. R. <pr...@cl...>]

Hi Sergio,

I wa the man who did the spanish traslation according with the supplied
instructions and some help from here.

Unluckyly, I can't put this to work in my site cause they don't allow
the gettext, maybe I can check this with another ISP. But I don't feel
comfortable with gettext oriented funcs, cause some ISP's don't use it.

Imagine how I feel .. :)

Pablo Roca


> -----Mensaje original-----
> De: php...@li...
> [mailto:php...@li...]En nombre de Sergio A.
> Kessler
> Enviado el: lunes, 04 de junio de 2001 2:37
> Para: php...@li...
> Asunto: [Phpwiki-talk] gettext problems
>
>
> hi all,
>
> I'm having problems with the locale, I cannot get spanish...
>
> of course I've edited the lib/config.php {$LANG = "es"},
> and according with phpinfo() I have gettext support and is active
>
> anyone using other locale than english with the php rpms from RedHat 7.1 ?
>
> TIA,
> /sergio
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] etc/*

[Sergio A. K. <ser...@ho...>]

putting the code where my mouth is, this patch create
a etc/* directory to put cfg there, so cleaning up index.php

comments ?

(the patch was made against the nigthly build, downloaded an hour ago)

/sergio

diff -Nur phpwiki.orig/etc/db.conf.php phpwiki/etc/db.conf.php
--- phpwiki.orig/etc/db.conf.php        Wed Dec 31 21:00:00 1969
+++ phpwiki/etc/db.conf.php        Mon Jun  4 11:50:10 2001
@@ -0,0 +1,49 @@
+<?php
+
+/////////////////////////////////////////////////////////////////////
+//
+// Part Two:
+// Database Selection
+//
+/////////////////////////////////////////////////////////////////////
+
+//
+// This array holds the parameters which select the database to use.
+//
+// Not all of these parameters are used by any particular DB backend.
+//
+$DBParams = array(
+   // Select the database type:
+   // Uncomment one of these, or leave all commented for the default
+   // data base type ('dba' if supported, else 'dbm'.)
+   //'dbtype' => 'dba',
+   //'dbtype' => 'dbm',
+   //'dbtype' => 'mysql',
+   'dbtype' => 'pgsql',
+   //'dbtype' => 'msql',
+   //'dbtype' => 'file',
+
+   // Used by all DB types:
+   'database' => 'wiki',
+   'prefix' => '',        // prefix for filenames or table names
+
+   // Used by 'dbm', 'dba', 'file'
+   'directory' => "/tmp",
+
+   // 'dbm' and 'dba create files named "$directory/${database}{$prefix}*".
+   // 'file' creates files named "$directory/${database}/{$prefix}*/*".
+   // The sql types use tables named "{$prefix}*"
+
+   // Used by 'dbm', 'dba'
+   'timeout' => 20,
+
+   // Used by *sql as neccesary to log in to server:
+   'server'   => 'localhost',
+   'port'     => '',
+   'socket'   => '',
+   'user'     => 'guest',
+   'password' => ''
+);
+
+
+?>
\ No newline at end of file
diff -Nur phpwiki.orig/etc/layout.conf.php phpwiki/etc/layout.conf.php
--- phpwiki.orig/etc/layout.conf.php        Wed Dec 31 21:00:00 1969
+++ phpwiki/etc/layout.conf.php        Mon Jun  4 11:52:40 2001
@@ -0,0 +1,93 @@
+<?php
+
+/////////////////////////////////////////////////////////////////////
+//
+// Part Three:
+// Page appearance and layout
+//
+/////////////////////////////////////////////////////////////////////
+
+// Select your language/locale - default language "C": English
+// other languages available: Dutch "nl", Spanish "es", German "de",
+// and Swedish "sv".
+//
+// Note that on some systems, apprently using these short forms for
+// the locale won't work.  On my home system 'LANG=de' won't result
+// in german pages.  Somehow the system must recognize the locale
+// as a valid locale before gettext() will work.  ('de_DE' works for
+// me.)
+putenv('LANG=es');
+
+// Setting the LANG environment variable (accomplished above) may or
+// may not be sufficient to cause PhpWiki to produce dates in your
+// native language.  (It depends on the configuration of the operating
+// system on your http server.)  The problem is that, e.g. 'de' is
+// often not a valid locale.
+//
+// A standard locale name is typically of  the  form
+// language[_territory][.codeset][@modifier],  where  language is
+// an ISO 639 language code, territory is an ISO 3166 country code,
+// and codeset  is  a  character  set or encoding identifier like
+// ISO-8859-1 or UTF-8.
+//
+// You can tailor the locale used for time and date formatting by setting
+// the LC_TIME environment variable.  You'll have to experiment to find
+// the correct setting:
+//putenv('LC_TIME=de_DE');
+
+// If you specify a relative URL for the CSS and images,
+// the are interpreted relative to DATA_PATH (see below).
+// (The default value of DATA_PATH is the directory in which
+// index.php (this file) resides.)
+
+// CSS location
+define("CSS_URL", "phpwiki.css");
+
+// logo image (path relative to index.php)
+$logo = "images/wikibase.png";
+
+// Signature image which is shown after saving an edited page
+// If this is left blank (or unset), the signature will be omitted.
+//$SignatureImg = "images/signature.png";
+
+// Date & time formats used to display modification times, etc.
+// Formats are given as format strings to PHP strftime() function
+// See http://www.php.net/manual/en/function.strftime.php for details.
+$datetimeformat = "%B %e, %Y";        // may contain time of day
+$dateformat = "%B %e, %Y";        // must not contain time
+
+// this defines how many page names to list when displaying
+// the MostPopular pages; the default is to show the 20 most popular pages
+define("MOST_POPULAR_LIST_LENGTH", 20);
+
+// this defines how many page names to list when displaying related pages
+define("NUM_RELATED_PAGES", 5);
+
+// Template files (filenames are relative to script position)
+// However, if a LANG is set, they we be searched for in a locale
+// specific location first.
+$templates = array("BROWSE" =>    "templates/browse.html",
+                   "EDITPAGE" =>  "templates/editpage.html",
+                   "MESSAGE" =>   "templates/message.html");
+
+/* WIKI_PGSRC -- specifies the source for the initial page contents
+ * of the Wiki.  The setting of WIKI_PGSRC only has effect when
+ * the wiki is accessed for the first time (or after clearing the
+ * database.) WIKI_PGSRC can either name a directory or a zip file.
+ * In either case WIKI_PGSRC is scanned for files --- one file per page.
+ */
+define('WIKI_PGSRC', "pgsrc"); // Default (old) behavior.
+//define('WIKI_PGSRC', 'wiki.zip'); // New style.
+
+// DEFAULT_WIKI_PGSRC is only used when the language is *not*
+// the default (English) and when reading from a directory:
+// in that case some English pages are inserted into the wiki as well
+// DEFAULT_WIKI_PGSRC defines where the English pages reside
+// FIXME: is this really needed?  Can't we just copy
+//  these pages into the localized pgsrc?
+define('DEFAULT_WIKI_PGSRC', "pgsrc");
+// These are the pages which will get loaded from DEFAULT_WIKI_PGSRC.
+$GenericPages = array("ReleaseNotes", "SteveWainstead", "TestPage");
+
+
+?>
\ No newline at end of file
diff -Nur phpwiki.orig/etc/main.conf.php phpwiki/etc/main.conf.php
--- phpwiki.orig/etc/main.conf.php        Wed Dec 31 21:00:00 1969
+++ phpwiki/etc/main.conf.php        Mon Jun  4 11:49:00 2001
@@ -0,0 +1,61 @@
+<?php
+
+/*
+  This is the starting file for PhpWiki. All this file does
+   is set configuration options, and at the end of the file
+   it includes() the file lib/main.php, where the real action begins.
+
+   This file is divided into six parts: Parts Zero, One, Two, Three,
+   Four and Five. Each one has different configuration settings you
+   can change; in all cases the default should work on your system,
+   however, we recommend you tailor things to your particular setting.
+*/
+
+/////////////////////////////////////////////////////////////////////
+// Part Zero: If PHP needs help in finding where you installed the
+//   rest of the PhpWiki code, you can set the include_path here.
+//ini_set('include_path', '.:/where/you/installed/phpwiki');
+
+/////////////////////////////////////////////////////////////////////
+// Part Null: Don't touch this!
+
+define ('PHPWIKI_VERSION', '1.3.0pre');
+require "lib/prepend.php";
+rcs_id('$Id: index.php,v 1.16 2001/04/07 00:34:30 dairiki Exp $');
+
+/////////////////////////////////////////////////////////////////////
+//
+// Part One:
+// Authentication and security settings:
+//
+/////////////////////////////////////////////////////////////////////
+
+// If set, we will perform reverse dns lookups to try to convert the users
+// IP number to a host name, even if the http server didn't do it for us.
+define('ENABLE_REVERSE_DNS', true);
+
+// Username and password of administrator.
+// Set these to your preferences. For heaven's sake
+// pick a good password!
+define('ADMIN_USER', "");
+define('ADMIN_PASSWD', "");
+
+// If true, only the admin user can make zip dumps, else
+// zip dumps require no authentication.
+define('ZIPDUMP_AUTH', false);
+
+// The maximum file upload size.
+define('MAX_UPLOAD_SIZE', 16 * 1024 * 1024);
+
+// If the last edit is older than MINOR_EDIT_TIMEOUT seconds, the default
+// state for the "minor edit" checkbox on the edit page form will be off.
+define("MINOR_EDIT_TIMEOUT", 7 * 24 * 3600);
+
+// Actions listed in this array will not be allowed.
+//$DisabledActions = array('dumpserial', 'loadfile');
+
+// PhpWiki can generate an access_log (in "NCSA combined log" format)
+// for you.  If you want one, define this to the name of the log file.
+define('ACCESS_LOG', '/tmp/wiki_access_log');
+
+?>
diff -Nur phpwiki.orig/etc/misc.conf.php phpwiki/etc/misc.conf.php
--- phpwiki.orig/etc/misc.conf.php        Wed Dec 31 21:00:00 1969
+++ phpwiki/etc/misc.conf.php        Mon Jun  4 11:53:36 2001
@@ -0,0 +1,102 @@
+<?php
+
+/////////////////////////////////////////////////////////////////////
+//
+// Part four:
+// Mark-up options.
+//
+/////////////////////////////////////////////////////////////////////
+
+// allowed protocols for links - be careful not to allow "javascript:"
+// URL of these types will be automatically linked.
+// within a named link [name|uri] one more protocol is defined: phpwiki
+$AllowedProtocols = "http|https|mailto|ftp|news|gopher";
+
+// URLs ending with the following extension should be inlined as images
+$InlineImages = "png|jpg|gif";
+
+// Perl regexp for WikiNames ("bumpy words")
+// (?<!..) & (?!...) used instead of '\b' because \b matches '_' as well
+$WikiNameRegexp =
"(?<![[:alnum:]])([[:upper:]][[:lower:]]+){2,}(?![[:alnum:]])";
+
+// InterWiki linking -- wiki-style links to other wikis on the web
+//
+// Intermap file for InterWikiLinks -- define other wikis there
+// Leave this undefined to disable InterWiki linking.
+define('INTERWIKI_MAP_FILE', "lib/interwiki.map");
+
+/////////////////////////////////////////////////////////////////////
+//
+// Part five:
+// URL options -- you can probably skip this section.
+//
+/////////////////////////////////////////////////////////////////////
+/******************************************************************
+ *
+ * The following section contains settings which you can use to tailor
+ * the URLs which PhpWiki generates.
+ *
+ * Any of these parameters which are left undefined will be
+ * deduced automatically.  You need only set them explicitly
+ * if the auto-detected values prove to be incorrect.
+ *
+ * In most cases the auto-detected values should work fine,
+ * so hopefully you don't need to mess with this section.
+ *
+ ******************************************************************/
+
+/*
+ * Canonical name and httpd port of the server on which this
+ * PhpWiki resides.
+ */
+//define('SERVER_NAME', 'some.host.com');
+//define('SERVER_PORT', 80);
+
+/*
+ * Absolute URL (from the server root) of the PhpWiki
+ * script.
+ */
+//define('SCRIPT_NAME', '/some/where/index.php');
+
+/*
+ * Absolute URL (from the server root) of the directory
+ * in which relative URL's for images and other support files
+ * are interpreted.
+ */
+//define('DATA_PATH', '/some/where');
+
+/*
+ * Define to 'true' to use PATH_INFO to pass the pagename's.
+ * e.g. http://www.some.where/index.php/HomePage instead
+ * of http://www.some.where/index.php?pagename=HomePage
+ * FIXME: more docs (maybe in README).
+ */
+//define('USE_PATH_INFO', false);
+
+/*
+ * VIRTUAL_PATH is the canonical URL path under which your
+ * your wiki appears.  Normally this is the same as
+ * dirname(SCRIPT_NAME), however using, e.g. apaches mod_actions
+ * (or mod_rewrite), you can make it something different.
+ *
+ * If you do this, you should set VIRTUAL_PATH here.
+ *
+ * E.g. your phpwiki might be installed at at /scripts/phpwiki/index.php,
+ * but  * you've made it accessible through eg. /wiki/HomePage.
+ *
+ * One way to do this is to create a directory named 'wiki' in your
+ * server root.  The directory contains only one file: an .htaccess
+ * file which reads something like:
+ *
+ *    Action x-phpwiki-page /scripts/phpwiki/index.php
+ *    SetHandler x-phpwiki-page
+ *    DirectoryIndex /scripts/phpwiki/index.php
+ *
+ * In that case you should set VIRTUAL_PATH to '/wiki'.
+ *
+ * (VIRTUAL_PATH is only used if USE_PATH_INFO is true.)
+ */
+//define('VIRTUAL_PATH', '/SomeWiki');
+
+
+?>
\ No newline at end of file
diff -Nur phpwiki.orig/index.php phpwiki/index.php
--- phpwiki.orig/index.php        Fri Apr  6 21:34:30 2001
+++ phpwiki/index.php        Mon Jun  4 11:54:52 2001
@@ -1,302 +1,9 @@
 <?php

-/*
-  This is the starting file for PhpWiki. All this file does
-   is set configuration options, and at the end of the file
-   it includes() the file lib/main.php, where the real action begins.
-
-   This file is divided into six parts: Parts Zero, One, Two, Three,
-   Four and Five. Each one has different configuration settings you
-   can change; in all cases the default should work on your system,
-   however, we recommend you tailor things to your particular setting.
-*/
-
-/////////////////////////////////////////////////////////////////////
-// Part Zero: If PHP needs help in finding where you installed the
-//   rest of the PhpWiki code, you can set the include_path here.
-
-
-//ini_set('include_path', '.:/where/you/installed/phpwiki');
-
-/////////////////////////////////////////////////////////////////////
-// Part Null: Don't touch this!
-
-define ('PHPWIKI_VERSION', '1.3.0pre');
-require "lib/prepend.php";
-rcs_id('$Id: index.php,v 1.16 2001/04/07 00:34:30 dairiki Exp $');
-
-/////////////////////////////////////////////////////////////////////
-//
-// Part One:
-// Authentication and security settings:
-//
-/////////////////////////////////////////////////////////////////////
-
-// If set, we will perform reverse dns lookups to try to convert the users
-// IP number to a host name, even if the http server didn't do it for us.
-define('ENABLE_REVERSE_DNS', true);
-
-// Username and password of administrator.
-// Set these to your preferences. For heaven's sake
-// pick a good password!
-define('ADMIN_USER', "");
-define('ADMIN_PASSWD', "");
-
-// If true, only the admin user can make zip dumps, else
-// zip dumps require no authentication.
-define('ZIPDUMP_AUTH', false);
-
-// The maximum file upload size.
-define('MAX_UPLOAD_SIZE', 16 * 1024 * 1024);
-
-// If the last edit is older than MINOR_EDIT_TIMEOUT seconds, the default
-// state for the "minor edit" checkbox on the edit page form will be off.
-define("MINOR_EDIT_TIMEOUT", 7 * 24 * 3600);
-
-// Actions listed in this array will not be allowed.
-//$DisabledActions = array('dumpserial', 'loadfile');
-
-// PhpWiki can generate an access_log (in "NCSA combined log" format)
-// for you.  If you want one, define this to the name of the log file.
-define('ACCESS_LOG', '/tmp/wiki_access_log');
-
-/////////////////////////////////////////////////////////////////////
-//
-// Part Two:
-// Database Selection
-//
-/////////////////////////////////////////////////////////////////////
-
-//
-// This array holds the parameters which select the database to use.
-//
-// Not all of these parameters are used by any particular DB backend.
-//
-$DBParams = array(
-   // Select the database type:
-   // Uncomment one of these, or leave all commented for the default
-   // data base type ('dba' if supported, else 'dbm'.)
-   //'dbtype' => 'dba',
-   //'dbtype' => 'dbm',
-   //'dbtype' => 'mysql',
-   //'dbtype' => 'pgsql',
-   //'dbtype' => 'msql',
-   //'dbtype' => 'file',
-
-   // Used by all DB types:
-   'database' => 'wiki',
-   'prefix' => '',        // prefix for filenames or table names
-
-   // Used by 'dbm', 'dba', 'file'
-   'directory' => "/tmp",
-
-   // 'dbm' and 'dba create files named "$directory/${database}{$prefix}*".
-   // 'file' creates files named "$directory/${database}/{$prefix}*/*".
-   // The sql types use tables named "{$prefix}*"
-
-   // Used by 'dbm', 'dba'
-   'timeout' => 20,
-
-   // Used by *sql as neccesary to log in to server:
-   'server'   => 'localhost',
-   'port'     => '',
-   'socket'   => '',
-   'user'     => 'guest',
-   'password' => ''
-);
-
-
-/////////////////////////////////////////////////////////////////////
-//
-// Part Three:
-// Page appearance and layout
-//
-/////////////////////////////////////////////////////////////////////
-
-// Select your language/locale - default language "C": English
-// other languages available: Dutch "nl", Spanish "es", German "de",
-// and Swedish "sv".
-//
-// Note that on some systems, apprently using these short forms for
-// the locale won't work.  On my home system 'LANG=de' won't result
-// in german pages.  Somehow the system must recognize the locale
-// as a valid locale before gettext() will work.  ('de_DE' works for
-// me.)
-putenv('LANG=C');
-
-// Setting the LANG environment variable (accomplished above) may or
-// may not be sufficient to cause PhpWiki to produce dates in your
-// native language.  (It depends on the configuration of the operating
-// system on your http server.)  The problem is that, e.g. 'de' is
-// often not a valid locale.
-//
-// A standard locale name is typically of  the  form
-// language[_territory][.codeset][@modifier],  where  language is
-// an ISO 639 language code, territory is an ISO 3166 country code,
-// and codeset  is  a  character  set or encoding identifier like
-// ISO-8859-1 or UTF-8.
-//
-// You can tailor the locale used for time and date formatting by setting
-// the LC_TIME environment variable.  You'll have to experiment to find
-// the correct setting:
-//putenv('LC_TIME=de_DE');
-
-// If you specify a relative URL for the CSS and images,
-// the are interpreted relative to DATA_PATH (see below).
-// (The default value of DATA_PATH is the directory in which
-// index.php (this file) resides.)
-
-// CSS location
-define("CSS_URL", "phpwiki.css");
-
-// logo image (path relative to index.php)
-$logo = "images/wikibase.png";
-
-// Signature image which is shown after saving an edited page
-// If this is left blank (or unset), the signature will be omitted.
-//$SignatureImg = "images/signature.png";
-
-// Date & time formats used to display modification times, etc.
-// Formats are given as format strings to PHP strftime() function
-// See http://www.php.net/manual/en/function.strftime.php for details.
-$datetimeformat = "%B %e, %Y";        // may contain time of day
-$dateformat = "%B %e, %Y";        // must not contain time
-
-// this defines how many page names to list when displaying
-// the MostPopular pages; the default is to show the 20 most popular pages
-define("MOST_POPULAR_LIST_LENGTH", 20);
-
-// this defines how many page names to list when displaying related pages
-define("NUM_RELATED_PAGES", 5);
-
-// Template files (filenames are relative to script position)
-// However, if a LANG is set, they we be searched for in a locale
-// specific location first.
-$templates = array("BROWSE" =>    "templates/browse.html",
-                   "EDITPAGE" =>  "templates/editpage.html",
-                   "MESSAGE" =>   "templates/message.html");
-
-/* WIKI_PGSRC -- specifies the source for the initial page contents
- * of the Wiki.  The setting of WIKI_PGSRC only has effect when
- * the wiki is accessed for the first time (or after clearing the
- * database.) WIKI_PGSRC can either name a directory or a zip file.
- * In either case WIKI_PGSRC is scanned for files --- one file per page.
- */
-define('WIKI_PGSRC', "pgsrc"); // Default (old) behavior.
-//define('WIKI_PGSRC', 'wiki.zip'); // New style.
-
-// DEFAULT_WIKI_PGSRC is only used when the language is *not*
-// the default (English) and when reading from a directory:
-// in that case some English pages are inserted into the wiki as well
-// DEFAULT_WIKI_PGSRC defines where the English pages reside
-// FIXME: is this really needed?  Can't we just copy
-//  these pages into the localized pgsrc?
-define('DEFAULT_WIKI_PGSRC', "pgsrc");
-// These are the pages which will get loaded from DEFAULT_WIKI_PGSRC.
-$GenericPages = array("ReleaseNotes", "SteveWainstead", "TestPage");
-
-/////////////////////////////////////////////////////////////////////
-//
-// Part four:
-// Mark-up options.
-//
-/////////////////////////////////////////////////////////////////////
-
-// allowed protocols for links - be careful not to allow "javascript:"
-// URL of these types will be automatically linked.
-// within a named link [name|uri] one more protocol is defined: phpwiki
-$AllowedProtocols = "http|https|mailto|ftp|news|gopher";
-
-// URLs ending with the following extension should be inlined as images
-$InlineImages = "png|jpg|gif";
-
-// Perl regexp for WikiNames ("bumpy words")
-// (?<!..) & (?!...) used instead of '\b' because \b matches '_' as well
-$WikiNameRegexp =
"(?<![[:alnum:]])([[:upper:]][[:lower:]]+){2,}(?![[:alnum:]])";
-
-// InterWiki linking -- wiki-style links to other wikis on the web
-//
-// Intermap file for InterWikiLinks -- define other wikis there
-// Leave this undefined to disable InterWiki linking.
-define('INTERWIKI_MAP_FILE', "lib/interwiki.map");
-
-/////////////////////////////////////////////////////////////////////
-//
-// Part five:
-// URL options -- you can probably skip this section.
-//
-/////////////////////////////////////////////////////////////////////
-/******************************************************************
- *
- * The following section contains settings which you can use to tailor
- * the URLs which PhpWiki generates.
- *
- * Any of these parameters which are left undefined will be
- * deduced automatically.  You need only set them explicitly
- * if the auto-detected values prove to be incorrect.
- *
- * In most cases the auto-detected values should work fine,
- * so hopefully you don't need to mess with this section.
- *
- ******************************************************************/
-
-/*
- * Canonical name and httpd port of the server on which this
- * PhpWiki resides.
- */
-//define('SERVER_NAME', 'some.host.com');
-//define('SERVER_PORT', 80);
-
-/*
- * Absolute URL (from the server root) of the PhpWiki
- * script.
- */
-//define('SCRIPT_NAME', '/some/where/index.php');
-
-/*
- * Absolute URL (from the server root) of the directory
- * in which relative URL's for images and other support files
- * are interpreted.
- */
-//define('DATA_PATH', '/some/where');
-
-/*
- * Define to 'true' to use PATH_INFO to pass the pagename's.
- * e.g. http://www.some.where/index.php/HomePage instead
- * of http://www.some.where/index.php?pagename=HomePage
- * FIXME: more docs (maybe in README).
- */
-//define('USE_PATH_INFO', false);
-
-/*
- * VIRTUAL_PATH is the canonical URL path under which your
- * your wiki appears.  Normally this is the same as
- * dirname(SCRIPT_NAME), however using, e.g. apaches mod_actions
- * (or mod_rewrite), you can make it something different.
- *
- * If you do this, you should set VIRTUAL_PATH here.
- *
- * E.g. your phpwiki might be installed at at /scripts/phpwiki/index.php,
- * but  * you've made it accessible through eg. /wiki/HomePage.
- *
- * One way to do this is to create a directory named 'wiki' in your
- * server root.  The directory contains only one file: an .htaccess
- * file which reads something like:
- *
- *    Action x-phpwiki-page /scripts/phpwiki/index.php
- *    SetHandler x-phpwiki-page
- *    DirectoryIndex /scripts/phpwiki/index.php
- *
- * In that case you should set VIRTUAL_PATH to '/wiki'.
- *
- * (VIRTUAL_PATH is only used if USE_PATH_INFO is true.)
- */
-//define('VIRTUAL_PATH', '/SomeWiki');
-
-
-////////////////////////////////////////////////////////////////
-// Okay... fire up the code:
-////////////////////////////////////////////////////////////////
+include "etc/main.conf.php";
+include "etc/db.conf.php";
+include "etc/layout.conf.php";
+include "etc/misc.conf.php";

 include "lib/main.php";

@@ -304,5 +11,5 @@
 // Local Variables:
 // mode: php
 // c-file-style: "ellemtel"
-// End:
+// End:
 ?>

Re: [Phpwiki-talk] gettext problems

[Sergio A. K. <ser...@ho...>]

----- Original Message -----
From: "Jon Åslund" <d9...@na...>


On Sun, Jun 03, 2001 at 09:36:58PM -0300, Sergio A. Kessler wrote:
> > anyone using other locale than english with the php rpms from RedHat 7.1
?
>
> No, sorry! It probably won't work with PhpWiki 1.2.0. Someone with
> better knowledge than me can fill in why (like Jan :), but it has been
> fixed and if you download the latest alpha version you can probably
> get it to run. Just did to make sure I was right, and I was. :)
>
>  ftp://phpwiki.sourceforge.net/pub/phpwiki/phpwiki.nightly.tar.gz
>
> Although there may be some other unfinished things in it, like for an
> example that ugly default style sheet (changing to sans serif for
> WikiLinks, baaah :).

I get it to work, but now I get the spanish text AND the english text
on the home page, like:

AgregarPaginas
from plain file ./locale/es/pgsrc/AgregarPaginas is identical to current
version 1 - skipped
AddingPages
Skipping

of course this is not what I want...
anyways, I started to look at the code, wow, well, it is not the
most elegant code I've seen...

the first thing that come to my mind is to create a /etc directory
to store there config files, the current method of storing config
info in index.php is b0rked (and a complete mess)

I'm willing to contribute a patch if this is of interest to
mantainers, just tell me.

/sergio

Re: [Phpwiki-talk] gettext problems

[Jon <d9...@na...>]

On Sun, Jun 03, 2001 at 09:36:58PM -0300, Sergio A. Kessler wrote:
> hi all,
>=20
> I'm having problems with the locale, I cannot get spanish...
>=20
> of course I've edited the lib/config.php {$LANG =3D "es"},=20
> and according with phpinfo() I have gettext support and is active
>=20
> anyone using other locale than english with the php rpms from RedHat 7.=
1 ?

No, sorry! It probably won't work with PhpWiki 1.2.0. Someone with
better knowledge than me can fill in why (like Jan :), but it has been
fixed and if you download the latest alpha version you can probably
get it to run. Just did to make sure I was right, and I was. :)

 ftp://phpwiki.sourceforge.net/pub/phpwiki/phpwiki.nightly.tar.gz

Although there may be some other unfinished things in it, like for an
example that ugly default style sheet (changing to sans serif for
WikiLinks, baaah :).

--=20
___\ Jon =C5slund

[Phpwiki-talk] gettext problems

[Sergio A. K. <ser...@ho...>]

hi all,

I'm having problems with the locale, I cannot get spanish...

of course I've edited the lib/config.php {$LANG = "es"}, 
and according with phpinfo() I have gettext support and is active

anyone using other locale than english with the php rpms from RedHat 7.1 ?

TIA,
/sergio

Re: [Phpwiki-talk] [dutch] translation update

[Jeff D. <da...@da...>]

>Well, I would like a new stable version instead. :) Can't we just
>feature freeze soon or are there many halfimplemented things in the
>main branch that need improvements?

The answer is "b) there are many halfimplemented things".  Mostly the
new database backend (which will allow multiple archived versions
of each page, and hopefully tie in to the quest for user authentication
abilities.)  I'm supposed to be working on that.  I'll see if I can =

produce something soon.  (Probably a couple of weeks.)


That said, the "alpha" branch does seem to be becoming popular.
Even if more big changes are anticipated, perhaps it's time for
a 1.3.1 release?  (Again with the understanding that those who
want real stability should stick with the 1.2.x branch.)


And: is it time for 1.2.1?  There have been a bunch of bug fixes since 1.=
2.
OTOH, things maybe worth waiting for (before 1.2.1) (?):
 * Marco has promised a few typo fixes for his Italian translations.
 * Should we fix the case-(in)sensitivity in page name bug(s) in the
   stable branch, or just leave it?  (SF bug # 233898).



>If you are on a PHP_SAFE_MODE system, do PhpWiki work like it's
>supposed to? I guess you can't mess much with environment variables at
>all.

Yes, now that you (and Jan) mention it, that is a problem.
Oh well.  Maybe things are best left as they (now are).
(With perhaps a little cleanup regarding LC_CTIME.)

>Yes. Have a test script that you can run to check if everything works
>ok.

Yes.  Adding some general regression and/or unit tests might be a good th=
ing
to think about (for everything, not just the setlocale() issues).  A lot
of work though....

Jeff

Re: [Phpwiki-talk] [dutch] translation update

[Jon <d9...@na...>]

On Thu, May 31, 2001 at 11:07:37AM -0700, Jeff Dairiki wrote:

> Thank you for the fixes.  I've checked them in to the CVS main branch.
> (I have not back-ported any of your translation fixes to the stable
> branch of the CVS --- should they be?)

Well, I would like a new stable version instead. :) Can't we just
feature freeze soon or are there many halfimplemented things in the
main branch that need improvements?

I will soon update the Swedish translation to be up to date with the
main branch. I've just used CVS for a project in school so I know how
to use it and I can probably check in the update myself, although I'm
always scared to destroy something. :)

> My changes (which worked on the systems I have access to)
> were an attempt to keep the localization config information in system
> environment variables.  This is, I think, a good idea, since it's the
> normal way to do things.  (On some systems, the environment variables
> might already be set correctly, and require no adjustment by the
> phpwiki administrator.  Who knows?)

If you are on a PHP_SAFE_MODE system, do PhpWiki work like it's
supposed to? I guess you can't mess much with environment variables at
all.

> That said --- getting the locale stuff to work seems to be highly syste=
m
> dependent.  What works seems depends on:
>=20
>   * PHP version and configuration
>   * OS type/version
>   * libc type/version
>   * who knows what else?

The power of three? (yes, I just watched The Charmed Ones :)

> "We" should probably make a concerted effort to come up with a language
> selection scheme which works reliably on as wide a range of systems as
> possible.  (Perhaps we need to construct a robust test program and/or
> start a page on the wiki for test reports of what does and does not wor=
k.)

Yes. Have a test script that you can run to check if everything works
ok.

--=20
___\ Jon =C5slund

Re: [Phpwiki-talk] [dutch] translation update

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

Jeff Dairiki <da...@da...> writes:

> Thank you for the fixes.  I've checked them in to the CVS main branch.

Ok, thanks, I'll have  a look.

> (I have not back-ported any of your translation fixes to the stable
> branch of the CVS --- should they be?)

Nah, not worth the effort imo.

> It's the "alpha" branch.   The system is working as it should:  Someone makes
> changes (that work for him, on the systems he has access to), and others tell
> him if it's broken.

Yes, that's what I guessed.  It seems indeed that php has problems to.
I find it strange that there's no mention in the weekly updates; but I
must confess that I haven't checked or looked for a php bugs list or
bugzilla or something.

> "We" should probably make a concerted effort to come up with a language
> selection scheme which works reliably on as wide a range of systems as
> possible.  (Perhaps we need to construct a robust test program and/or
> start a page on the wiki for test reports of what does and does not work.)

That's a good idea.  There's another small thing, when php runs in
safe mode, you can't putenv (), there must be a solution for that too.

Greetings,
Jan.

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