phpwiki-talk

Re: [Phpwiki-talk] Some new graphics for Wiki

[Carsten K. <car...@ma...>]

Hi Russ,

The buttons were made using Apple's ProjectBuilder and InterfaceBuilder 
(shameless plug: two Apple OS X tools that work with gcc/gdb for compiling 
applications). Then I took a screen snapshot, chopped it into individual 
PNG files and massage them further.

Some of the buttons are already finished and posted on my web site. I'm 
putting up some more tonight. I'll also include a couple blank buttons so 
anyone who wants to can add in their own icons.

<http://homepage.mac.com/carstenklapp/web-buttons/>

    *   *   *

I'm excited about a little php script I found that uses GD and FreeType to 
create images on-the-fly. While I don't think it would be very efficient 
for PhpWiki to use it to render all images on the fly, this will be very 
helpful to create many localized translations of any buttons which contain 
text.

<http://www.entropy.ch/software/macosx/php/> look at the Aqua button 
example abut halfway down the page.

Carsten

On Friday, November 30, 2001, at 03:05  pm, Russ Miller wrote:

>> I'm working on some new graphics and optional button images for Wiki. The
>> shadows ae all achieved with PNG alpha channel masks so they will work on
>> any background color, even a texture pattern.
>>
>> Have a look at this screenshot of the first set of buttons. I appreciate
>> any feedback or comments you may have.
>>
>> <http://homepage.mac.com/carstenklapp/wiki-buttons.png> - 76 Kb
>
> my feedback is that those are great.
>
> i've got a wiki i've been tweaking, that is due to roll-out Dec. 14th. it'
> s
> based on the 1.2.2 code.
> Any chance of getting these before then? In the next week or so?
>
> Also, what graphics package are you using? Will you be putting out just 
> the
> PNG files, or some kind of source file that could be tweaked (i'm sure 
> with
> the new functionality i'll at least need additional buttons to fit the
> scheme)? I have Paintshop Pro available, and I could prolly get the Gimp
> going if i needed to.
>
> great work!
>
> russ
>

[Phpwiki-talk] wiki to html translator (fwd)

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

Date: Fri, 30 Nov 2001 12:50:00 -0800
From: Dan Bluestein <db...@sv...>
To: sw...@pa...
Subject: wiki to html translator

Hi, the sourceforge forums don't seem to be letting me post
so here's the message I tried to put up on the thread
http://sourceforge.net/forum/forum.php?thread_id=132230&forum_id=18928
-----

Well, sorry I missed your release (and the subsequent one
too -- but this stuff isn't exactly of the quality you'd
want to include in a release) but I have something basic:

http://scienceview3.lhs.berkeley.edu/~db/phpwiki-htmldump.tar.gz

This stuff was done based on phpWiki 1.2.0; I haven't tried
it with a newer version.

If anyone wants to try it out you can berate me for how bad
it is, or for forgetting to include some files in the
tarball, or for whatever, at db...@sv....  Anyway for
now it just meets our basic need of bringing the wiki
content on disk to somebody who has a browser but no net
connection, and that's about all it does...

cheers,
Dan

Re: [Phpwiki-talk] Some new graphics for Wiki

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

On a related note: I, for one, would be happy to see a new (or
alternative) PhpWiki logo.  A more logoistic one.  (Maybe incorporating,
or mangling, the PHP logo?)  Alas, I am no artist, so someone else had
better do it.

Re: [Phpwiki-talk] Some new graphics for Wiki

[Adam S. <ad...@pe...>]

> The different variations of Edit/EditText are merely to accommodate
> minor differences in PhpWiki 1.2 and 1.3.

ah that makes sense.

> The extra buttons at the bottom (Edittext with @ sign etc) weren't
> supposed to be in the picture. I removed them and updated the picture,
> also added a few from Moinmoin for you.

very nice, thanks!  i look forward to a theme which has these available!
:-)

adam.

Re: [Phpwiki-talk] Some new graphics for Wiki

[Carsten K. <car...@ma...>]

Hi Adam,

Thanks for your comments!

The different variations of Edit/EditText are merely to accommodate minor 
differences in PhpWiki 1.2 and 1.3.

1.2.2 has EditText, Info, Diff, FindPage, GoodStyle, EditLinks, EditCopy 
(edit previous archived version of a page)
1.3 has Edit, History, Diff, DebugInfo, FindPage, LikePages, SignIn.

The extra buttons at the bottom (Edittext with @ sign etc) weren't 
supposed to be in the picture. I removed them and updated the picture, 
also added a few from Moinmoin for you.

<http://homepage.mac.com/carstenklapp/wiki-buttons.png> - 80 Kb

Carsten

[Phpwiki-talk] textarea helper icons

[Adam S. <ad...@pe...>]

this is an interesting idea.  it's javascript based so it breaks steve's
keep it simple mantra but it might be worth having a theme available which
uses this.  it might also make html tags like <strong> and <nowiki> more
palettable.

    http://www.voidstar.com/node.php?id=235

also for those of you out there that are working on integrating phpwiki
into postnuke/phpnuke you really might want to check out drupal
(drop.org).  it's *sooooo* much nicer. :-)

adam.

[Phpwiki-talk] Some new graphics for Wiki

[Carsten K. <car...@ma...>]

Hi All,

I'm working on some new graphics and optional button images for Wiki. The 
shadows ae all achieved with PNG alpha channel masks so they will work on 
any background color, even a texture pattern.

Have a look at this screenshot of the first set of buttons. I appreciate 
any feedback or comments you may have.

<http://homepage.mac.com/carstenklapp/wiki-buttons.png> - 76 Kb

Carsten

Re: [Phpwiki-talk] Themes & languages (was Re: need help with cvs...)

[Carsten K. <car...@ma...>]

Good point, we can't rely on all servers using or isps allowing .htaccess 
files.

As a side note, .htaccess files are used by Netscape Enterprise Server, 
NCSA httpd and I think Microsoft FrontPage Server Extension as well as 
Apache.

Anyone else know about other servers? It might be helpful to include a 
couple of lines in the docs about security.

Carsten

On Thursday, November 29, 2001, at 06:31  am, Lawrence Akka wrote:

> At 20:26 28/11/2001, Adam Shand wrote:
>
>> > /admin
>> > .htaccess DENY
>>
>> one problem with this is you can't always rely on users being able to use
>> .htaccess files.  some isp's disable them on their web farms.
>>
>> i prefer to move all of my php code outside of my docroot (eg.
>> /var/lib/ptpwiki-1.3.1).
>>
>> adam.
>>
>
>
> Also, for some strange reason, not everyone runs Apache!
>

Re: [Phpwiki-talk] Bug: missing setStatus function

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

As it turns out, I never really, so much, _completed_ the logging code ---
so it was missing a lot more than just the setStatus method:-)

I think I've fixed it now.  (As a bonus, access logging should work now.)

Thanks for the report.

[Phpwiki-talk] Bug: missing setStatus function

[Lawrence A. <la...@20...>]

I have tried four times this morning to submit the following bug report to 
SF, but with no luck!

So here goes - re 1.3

lib/Request.php:   Request->redirect function.

This function calls $this_logentry->setStatus, but there is no such 
function defined in the Request_AccessLogEntry class.


This causes a problem when you try to delete all the text on a page (at 
least for me).

Lawrence


==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

Re: [Phpwiki-talk] Themes & languages (was Re: need help with cvs...)

[Lawrence A. <la...@20...>]

At 20:26 28/11/2001, Adam Shand wrote:

> > /admin
> > .htaccess DENY
>
>one problem with this is you can't always rely on users being able to use
>.htaccess files.  some isp's disable them on their web farms.
>
>i prefer to move all of my php code outside of my docroot (eg.
>/var/lib/ptpwiki-1.3.1).
>
>adam.
>


Also, for some strange reason, not everyone runs Apache!

Lawrence

ps - am I sneding HTML emails?  Sorry if I am - my client is playing 
up.  Could someone let me know.  Thanks


==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

Re: [Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

[Lawrence A. <la...@20...>]

At 02:06 29/11/2001, Jeff Dairiki wrote:
>On Wed, 28 Nov 2001 17:05:25 -0500
>"Carsten Klapp" <car...@ma...> wrote:
>
>
> > - move remaining files out of /admin (perhaps into "/lib")
>
>There's actually nothing in admin that is currently functional.
>Everything that gets used by the main code has already been moved
>to lib.  Just leave /admin alone for now --- we'll clean it up at
>some point.

As long as we don't forget :-)



> > - gather up installation notes, theme instructions & docs into "/doc"
>
>This can wait, too...  Steve's probably the one who should decide how to
>move the docs around.  We should probably leave at least one top-level
>README
>file to point people to the doc subdir.
>

I am very keen for this to happen.  I don't like the idea of having 
accessible docs in the root directory (even if they don't say anything 
confidential).  It is much cleaner and easier to control access if they are 
in a subdir.




> > - Keep the default "wikibase.png", "signature.png" and "png.png" in
>/images
> > - /themes/default/config.php will set $signature and $logo pointing to
> > /images
> > - any additional themes which need to include differently colored logos
> > etc. can place them in their theme directory, and its config.php would
> > point to it: "/themes/Forge/config.php" could specify
>$logo="/themes/Forge/
> > SteelyDanSig.png" etc.
>
>Personally, I'd really prefer if images would stay in the images
>subdirectory (since then, that's the only sub-tree which needs
>to be HTTP accessible, which makes life simpler for lots of people).
>If you want to put theme-specific graphics in subdirectories of /images
>that makes sense.  E.g. "$logo=themes/Forge/SteelyDanSig.png".

I agree with Jeff, but no strong views.

Lawrence




==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

Re: [Phpwiki-talk] About languages

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> <a href="http://..."><?=_("Some text.")_?></a>
                                         ^

oops: 
<a href="http://..."><?=_("Some text.")?></a>

Re: [Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>   o Have to pay attention to the HTTP cache-control headers when we
>     serve up the CSS, so that the browser doesn't have to reload it
>     for every page view.  (We should probably be paying more attention
>     to the cache-control headers anyway...)

i did it, but to summarize: easy to add but a nightmare with timezones.
almost every site I have a wiki installed has a different and wrong timezone 
setting. this in collaboration with various browsers on various systems.

mostly example summertime (CEST / CET) and localtime system support at all. 

windows is okay, but glibc2 <=2.2 doesn't work for me most of the time. 
i'm just too stupid so i hardcoded the abbrevation from GMT. works fine 
now with with IE/windows as browser.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] About languages

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>    <a href="http://..."><?php echo gettext("Some text."); ?></a>
> Perhaps we could support a more compact syntax...

<a href="http://..."><?=_("Some text.")_?></a>

should work. almost perl'ish :)
you have to enable the ASP tags syntax in php.ini (which is default)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

[Carsten K. <car...@ma...>]

Sounds reasonable to keep them in /images so it's the only dir accessible 
by http. Also, we're already talking about moving a whole bunch of stuff 
as it is, no point in warping our heads around too many new changes at 
once (well speaking for myself anyway). :-)

To everyone on the list: I'm sorry for moving files around without 
consulting the list first--I won't move anything else on the server for a 
while. Still having some trouble with my cvs client but I'm pretty sure I 
just need to do some more reading up on CVS.

On Wednesday, November 28, 2001, at 09:06  pm, Jeff Dairiki wrote:
>
> Personally, I'd really prefer if images would stay in the images
> subdirectory (since then, that's the only sub-tree which needs
> to be HTTP accessible, which makes life simpler for lots of people).
> If you want to put theme-specific graphics in subdirectories of /images
> that makes sense.  E.g. "$logo=themes/Forge/SteelyDanSig.png".
>
> I don't know how anybody else feels about this.  You might want to wait
> another day or so to see if anyone else pipes up.

Re: [Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

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

On Wed, 28 Nov 2001 17:05:25 -0500
"Carsten Klapp" <car...@ma...> wrote:

> - embed translatable strings in the templates, leaving only one set of 
> html templates in themes.

I've got that more or less done here at home.  I'll check it in within a
few hours.

> - style sheets served by php script (<link rel="stylesheet" 
> href="index.php?action=css" type="text/css" />)

I'll add this to my to-do list.  For now, let's just leave the
style sheets in the top level directory.  (Unless you write new
style sheets (for new themes), in which case put them in
themes/wherever/...)

> - move remaining files out of /admin (perhaps into "/lib")

There's actually nothing in admin that is currently functional.
Everything that gets used by the main code has already been moved
to lib.  Just leave /admin alone for now --- we'll clean it up at
some point.

> - gather up installation notes, theme instructions & docs into "/doc"

This can wait, too...  Steve's probably the one who should decide how to
move the docs around.  We should probably leave at least one top-level
README
file to point people to the doc subdir.

> - Keep the default "wikibase.png", "signature.png" and "png.png" in
/images
> - /themes/default/config.php will set $signature and $logo pointing to 
> /images
> - any additional themes which need to include differently colored logos 
> etc. can place them in their theme directory, and its config.php would 
> point to it: "/themes/Forge/config.php" could specify
$logo="/themes/Forge/
> SteelyDanSig.png" etc.

Personally, I'd really prefer if images would stay in the images
subdirectory (since then, that's the only sub-tree which needs
to be HTTP accessible, which makes life simpler for lots of people).
If you want to put theme-specific graphics in subdirectories of /images
that makes sense.  E.g. "$logo=themes/Forge/SteelyDanSig.png".

I don't know how anybody else feels about this.  You might want to wait
another day or so to see if anyone else pipes up.

[Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

[Carsten K. <car...@ma...>]

Excellent ideas. I agree with nearly everything except the images. To 
summarize then:

- embed translatable strings in the templates, leaving only one set of 
html templates in themes.
- templates inside top level of theme e.g. 
"/themes/default/browse.template" or "browse.tmpl"
- style sheets served by php script (<link rel="stylesheet" 
href="index.php?action=css" type="text/css" />)
- move remaining files out of /admin (perhaps into "/lib")
- gather up installation notes, theme instructions & docs into "/doc"
- name theme configuration script "/themes/default/config.php" (in "themes/
$theme/")
- "tests/unit_test_backend_cvs.php" accessible via http

Here's an idea I just thought of regarding the images.

- Keep the default "wikibase.png", "signature.png" and "png.png" in /images
- /themes/default/config.php will set $signature and $logo pointing to 
/images
- any additional themes which need to include differently colored logos 
etc. can place them in their theme directory, and its config.php would 
point to it: "/themes/Forge/config.php" could specify $logo="/themes/Forge/
SteelyDanSig.png" etc.

Carsten

Re: [Phpwiki-talk] Themes & languages (was Re: need help with cvs...)

[Adam S. <ad...@pe...>]

> /admin
> .htaccess DENY

one problem with this is you can't always rely on users being able to use
.htaccess files.  some isp's disable them on their web farms.

i prefer to move all of my php code outside of my docroot (eg.
/var/lib/ptpwiki-1.3.1).

adam.

Re: [Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

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

On Wed, 28 Nov 2001 11:45:13 -0800
"Jeff Dairiki" <da...@da...> wrote:

> Here's another crackpot idea.  Have the main phpwiki script (or another
> new php script) serve up the CSS stylesheets.

...

> Advantages:

One more, that I just thought of: the script can serve different style
sheets depending not only on user preference but also depending on
User-Agent.  This would eliminate the need for the "@import
url(phpwiki-heavy.css);" hack.

[Phpwiki-talk] Re: Themes & languages (was Re: need help with cvs...)

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

On Tue, 27 Nov 2001 19:02:17 -0500
"Carsten Klapp" <car...@ma...> wrote:

> -security
>   Below is another folder layout which I believe takes these issues into

> consideration. Templates for all the various languages can still be 
> grouped inside a locale folder within a theme, the whole 
> /themes/default/locale/ folder could be excluded from server access.

I think Lawrence's idea for embedding translatable strings in the
templates is a great idea which will eliminate the need for having a
separate template for each language.  With that, you only need one version
of each template for each theme (or even less? some themes may share
templates).

> -selection of style sheets independent of themes
>   -muliple style sheets can exist within /themes/default/, independent
of 
> language.

Here's another crackpot idea.  Have the main phpwiki script (or another
new php script) serve up the CSS stylesheets.  I.e. all the templates link
to the style sheet with:

  <link rel="stylesheet" href="index.php?action=css" type="text/css" />

When index.php is invoked with the action=css argument, it serves up the
style sheet from the file themes/default/phpwiki.css (or possibly some
other style sheet, depending on what the user has set in his preferences.)

Advantages:
  o Direct web access to phpwiki.css is not required.
  o Actual wiki HTML is completely independent of what style sheet
    the user has selected in his preferences.  (This might be a big
    win if we ever implement HTML caching, or if the wiki is served
    through a caching proxy.)

Disadvantages:
  o Wierd?
  o Have to pay attention to the HTTP cache-control headers when we
    serve up the CSS, so that the browser doesn't have to reload it
    for every page view.  (We should probably be paying more attention
    to the cache-control headers anyway...)


> Moving language specific stuff from index.php is a good idea too.
> [other good notes deleted]

To rephrase your notes (which I deleted):

There are basically two indepedent purposes for which we set language
preferences.  (Currently the config controls for these are all mangled
into one...)

 1) To select the initial pgsrc.

    Maybe we should fire up wikis with (perhaps selectable) pgsrc
    in multiple languages by default?

 2) To select run-time (gettext) translations (and also things like
    date and time formats)  (and currently also to select templates,
    though Lawrence's idea would eliminate that need altogether)

Just rambling, I guess, sorry...

More random comments on your proposed directory structure:
 
> /admin
> .htaccess DENY

  Admin seems mostly vestigal to me.  Can we do away with it altogether?

> /docs
> .htaccess DENY

  We don't have this now.  It's probably a good idea.  I think 'doc' would
be
  the more standard name.


> /tests
> .htaccess DENY

  tests/unit_test_backend_cvs.php currently need to be HTTP accessible to
be used.

> /themes
>         .htaccess ALLOW
>         /default
>          .htaccess ALLOW
>          -default.php
  If avoidable, this should not be HTTP accessible.  (It would be an error
to try to run it.)
  Also, since it's already in the themes/default subdirectory, why not
name it config.php,
  instead of the redundant themes/default/default.php?

>          -phpwiki.css
  My crackpot idea (above) would make it so that this need not be HTTP
accessible.

>          -wikibase.png
  Making the image files the only ones which still need to be directly
HTTP accessible.
  Because of this I still think they ought to go somewhere else... 

>          -themes.README
  Should go either in /themes or in /doc (or /), I would think.

> /themes/locale
  Probably not needed once we make templates non-language-dependent?
  (Templates can go directly in /themes/default.)



So, here would be my counter proposal (today, at least):

/images (.htaccess ALLOW)
   - wikibase.png

   Leave images here.

Get rid of /templates (& the templates in /locale) in favor of

/themes (.htaccess DENY)
  /default
    -config.php

    -default.css
    -default-heavy.css
    -psychadelic.css
     ...

    -browse.html  (or browse.tmpl)?
    ...
  /classic
    -config.php
    ...
 
 
Jeff

Re: [Phpwiki-talk] About languages

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

On Tue, 27 Nov 2001 19:09:21 +0100
"Jon =C5slund" <d9...@na...> wrote:

> I've just made a small update (po, pgrsc, and templates) to the
> Swedish translation of 1.2 (attached, I hope it's ok?)

Thanks!  I've just checked your patches into the CVS.

> ...and I'll fix it for the 1.3 line as well, but not tonight.

That's certainly not going to be a one night job.  I'd hold off for a bit
working on the templates, at least, for a bit.  I think Lawrence's idea t=
o
embed gettext-translated strings into the templates will make that job
much easier...

[Phpwiki-talk] Themes & languages (was Re: need help with cvs...)

[Carsten K. <car...@ma...>]

Hi Jeff,
You've raised some important issues which I didn't consider: security, 
rootless access and multiple wikis off the same codebase.

-rootless access to server
  I agree, without root access to the server DATA_PATH will still be needed 
after all.

-security
  Below is another folder layout which I believe takes these issues into 
consideration. Templates for all the various languages can still be 
grouped inside a locale folder within a theme, the whole 
/themes/default/locale/ folder could be excluded from server access.

-selection of style sheets independent of themes
  -muliple style sheets can exist within /themes/default/, independent of 
language.

Moving language specific stuff from index.php is a good idea too. The 
admin could then specify a default language and a theme and the wiki would 
be populated with the pgsrc from the default language, and the correct 
templates and text-messages would automatically be referenced.

With this folder layout a new user preference could be added for the 
language, users could choose any one of the languages available in the 
current theme and the wiki dynamically serves out the appropriate system 
text, messages, and menus. Of course the page contents themselves would 
not change.

Carsten

/admin
.htaccess DENY
/docs
.htaccess DENY
/lib
.htaccess DENY
/locale (or /data/locale)
        .htaccess DENY
        /de
           /messages
            -phpwiki.php
            -phpwiki.mo
           /pgsrc
            -MeistBesucht
            -GuterStil
            -SeitenErzeugen
            -GaesteBuch
            -SeiteFinden
            -PhpWikiAdministration
            -WieManWikiBenutzt
            -SandKiste
            -PhpWiki
            -WikiTechnik
            -KonvertiereLeerzeichenZuTabs
            -EditiereText
            -TextFormatierungsRegeln
            -WabiSabi
            -WikiWikiWeb
            -StartSeite
        /en
           /messages
           /pgsrc
        /es
           /messages
           /pgsrc
        /it
           /messages
           /pgsrc
        /nl
           /messages
           /pgsrc
        /po
           /messages
           /pgsrc
        /sv
           /messages
           /pgsrc
/schemas
.htaccess DENY
/tests
.htaccess DENY
/themes
        .htaccess ALLOW
        /default
         .htaccess ALLOW
         -default.php     (php file here only to define
                           variables for images, css names,
                           and future: optional button
                           graphics, logos etc.)
         -phpwiki.css
         -phpwiki-heavy.css
         -printer-color.css
         -printer-bw.css
         -largetext.css
         -handheld.css
         -wikibase.png
         -signature.png
         -themes.README
        /locale
               .htaccess DENY
               /de
                  /templates
                   -browse.html
                   -editpage.html
                   -message.html
               /en
                  /templates
               /es
                  /templates
               /it
                  /templates
               /nl
                  /templates
               /po
                  /templates
               /sv
                  /templates

#eof

Re: [Phpwiki-talk] About languages

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

On Wed, 28 Nov 2001 17:19:37 +0000
"Lawrence Akka" <la...@20...> wrote:

> What about {_WhateverText}.

The one other thing to consider is that it would be nice to use a syntax
which can be grokked by xgettext (which is designed for picking gettext()
calls out of C code).  Some options which work:

  gettext("string")
  $gettext("string")
  _("Text string")
  $_("string")

(The parentheses around a "-quoted string are the key.)

These are all somewhat ugly, but acceptable, I think.  Of the above
choices, I like $_("this one").

(The other option would be to write our own replacement or pre-filter for
xgettext. :-/ )



> >The _() abbreviation is standard usage --- the gettext tools support it
by
> >default.

Correction: GNU xgettext doesn't support _() by default, you must include
the '-k_' command line argument.  The _() is fairly standard usage
however, and stock PHP does define '_' as an alias for 'gettext'.

Re: [Phpwiki-talk] About languages

[Lawrence A. <la...@20...>]

At 16:40 28/11/2001, Jeff Dairiki wrote:
> > 3)  It seems to me to be asking for trouble to have to translate the
> > templates for each language.  Each time the template changed, the
> > translations would have to be updated.  Wouldn't it be better to have
> > language defines (as above), or even template variables in the template,
>
> > which are replaced by the Template munger appropriately, eg:
>
>Yes.  Good idea.
>
>This can more-or-less be done now (in 1.3), in an ugly fashion, as
>follows:
>
>    <a href="http://..."><?php echo gettext("Some text."); ?></a>
>
>Perhaps we could support a more compact syntax...
>

What about {_WhateverText}.

Template.php could then pick use a regexp to pick up {_(.*)}  (or whatever 
- not sure if that one works). and yank in the necessary translation.

WOuld only cause a problem if someone wanted to use {_ in their template.




>And while on the subject, my one nit about gettext is:
>
>For it's compactness, I much prefer
>    $msg = _("string");
>to
>    $msg = gettext("string");
>
>The _() abbreviation is standard usage --- the gettext tools support it by
>default.  (PHP, if gettext support is compiled in, supports the _() syntax
>already.  We'd have to define the '_' replacement function when there's no
>PHP gettext support if we were to start using it in PhpWiki code.)
>
>Does anyone have objections to the abbreviated syntax?

I agree.

Lawrence


==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...