[kdewebdev-site] Proposed PHP infrastructure

[Bill Chmura]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Chris,

Can you summarize what exactly this buys us and why?  I'm looking through it 
and like I mentioned to you before it seems really complicated for what we 
are doing.   Bear with me, as devil's advocate is my natural modus 
operandi... : )   I am still somewhat new with PHP, so anyone else that knows 
this stuff can also answer any of these or conversely ask questions.

* Can you see the result of work you just did on the web site in this system?  
To check formatting, appearance and such?  Your talking cron jobs and 
emailing files....

* You say there is only 3 steps of human interaction, but overall it seems 
like a lot of things have to happen for this to complete.  

* I am not sure we can have the kbabel on the server or whatnot.  We are in a 
shared environment and while they are being condusive, not sure if they are 
going be crazy about installing more stuff.

* I don't trust computer translators... Its all fun and games till you 
accidentally start WW3

* From what I am seeing this will be mostly for the front end... the back end 
is going to be so heavily oriented toward supporting development or user 
support that this may not fit in - Eric has some cool ideas for development 
support. 

Okay, thats my volley for now... Its just the concerns I have and I know 
you've been trying to get me to see the light on this one, but it still seems 
like overkill or at least a roundabout way to get somewhere - and I am still 
not sure where that is.  We are going to have plenty to do anyway - this just 
seems like it will make it more complicated than the site needs to be.

Bill



On Wednesday 03 March 2004 11:34 pm, Chris Hornbaker wrote:
> Hi, all.
>
> I've been working on, what I call, a content processor. It basically takes
> all the work out of Accessibility, Usability, PHP, navigation, and
> translation. Pages created with it are consistant, easy to use, and valid
> (you have to actually /try/ to make it invalid).
>
> So that I don't go into too many details, I'll just explain how it'll be
> used from a content creators point-of-view.
>
> First, the physical layout of the sites will be just as Eric said in a
> previous email, plus two:
> www/
> devel/
>
> www/ contains scripts for automation and common pages. Common pages
> consist of help, access key description, personalized styling and language
> selection, etc..
>
> devel/ contains all the not-to-be-seen-by-the-user files. The layout of
> this dir is exactly the same as the top-level, minus www/ and devel/ --
> it's duplicated.
>
> Within devel/ you place XML files, which contains essentially what can be
> contained in an XHTML <div>, plus a key element. The new element is
> <i18n>. This is used to wrap text that is to be translated. A cron job when
> run every <set of time> and will 1) replace the top and bottom of the file
> with PHP includes, 2) replace, for example,
> <p><i18n>string</i18n></p>
> with:
> <p><?php i18n("string"); ?></p>
>
> The cron job will then place the files in the "live" area (eg. the dirs
> Eric mentioned) in their correct location, after which another cron job
> will come through the "live" area and use xgettext to create .pot for
> translation via KBabel.
>
> Once a .pot file is translated, the translator emails it to someone and
> they place it in a dir within www/  Another cron job will come trough that
> dir and convert the .pot files to PHP includes.
>
> (Note: Only three steps of human interference: content creation,
> translation, and placing translated files in a dir.)
>
> (See the attached accesskeys.xml file for an example XML file and
> accesskeys.phps for an example generated PHP file.)
>
> Navigation is made up of simple PHP. See attached example menu.inc file
> -- it can't get any simplier. :-) Here's an example entry:
> $section->appendURI(i18nVar("Who is Chris Hornbaker?"),"aboutme", "W",
> true);
>
> The first arg is the text that the user will see. The second is what will
> go into href="". The third is the character to be highlighted (//FIXME: for
> other langs). The last arg specifies if it's a dir or file.
>
> Lastly, on the developer's end, is CSS. Pages generated with the code are
> 100% customizible. At no point is XHTML used to style the page.
>
> That's really all there is on the developer's end. Some quirks that need
> worked out, but overall it's functional and does a great job, and, with
> this team, it shouldn't take much time to resolve them with a good
> solution.
>
> To see a funtioning example, see my site http://jilks.no-ip.org/  (note: I
> don't work on my site much, so parts aren't existing).
>
> Thoughts?

- -- 

Bill Chmura
bill at kdewebdev.org
KdeWebDev/Quanta site development project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFARsUhEEA64RcvcRERAiduAJ9Q39O0sKK+PAjSbx8d3HxnTUY9iQCgsEO6
kTYaNtQm/wYS/peB6oszYmA=
=qK1a
-----END PGP SIGNATURE-----