[kdewebdev-site] Proposed PHP infrastructure

[Eric Laffoon]

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

On Wednesday 03 March 2004 8: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.

There is more than one way to go about this. I just don't have time to 
evaluate it at this moment. Maybe next week. Jacob Coby asks some very good 
questions. Initially as I say, there are several ways to go about things and 
I think it's important that these undergo more of a process review of active 
developers and more of a collaborative development, but then that looks like 
what we have going on here. I know Chris can get excited and charge forward 
and he has some really good stuff, but also can miss some factors that look 
different from a perspective of longer application.

My initial response to this was that it may be overly complicated, but that's 
really unfair until I look at it more. There are two points of interest... 
that it was inspired by what is done at kde.org is of nominal interest, but 
not to be ignored. The point I find most intriguing is the i18n stuff. 
There's definitely other ways of doing this, and I think we need to let Bill 
focus the project on the sequence of getting ready to have our layout 
submitted for graphic design, then move forward. I've been holding off on 
submitting some things out of respect for that rational organization...

Anyway, WRT to the i18n stuff... I haven't done much with translation. I think 
a lot of guys doing web sites that speak different languages could easily 
work with include files or XML files. Initially my concept was to do XML 
based content. After I review what Chris has done I may submit some alternate 
ideas for discussion. However all the ideas have a certain degree of ugliness 
from some perspective and we need to pick our favorite ugly. So this brings 
up two really good questions for Chris...

1) What is the basis for using the i18n approach from the standpoint of 
translator availability. In other words, are you thinking the the KDE 
translators would do this? (an interesting idea we might consider presenting 
to them) Is there some basis to assume that this would be the prevailing bias 
of translators as opposed to directly translating?

2) Assuming the first is not highly positive and given my lack of experience 
with kbabel is there a compelling reason (from the perspective of the people 
translating) to encourage translating web developers to adopt additional 
tools here, by which I mean kbabel? Keep in mind that alternate methods could 
accomplish the same goal so merely achieving the result is not persuasive.

There is a third factor too which is how well what is presented can integrate 
with other procedures and code. For instance a PHP template system or BBS 
package may largely dictate how things done with it are handled where as 
additional functions to process specifics like text strings may be less 
invasive to an open design procedure. My preference is to facilitate the good 
experiences of the team and accepted constraints have to be very persuasive. 
Again this is from the technical standpoint...

We still need to address Bill's layout concerns.

Bill, could you post your menus in the following layout for review so we can 
finalize? This would be easiest for me...
Definition - 
[A] ... [/A] = menu block
menuitem = menu to a page that does not create secondary menus
menuitem ... = menu to a page that does create secondary menus
[A.B] ... [/A.B] = B is secondary menu to A
===
[main]
item 1 
quanta ...
...
item n
[/main]

[quanta]
item 1 
support ...
...
item n
[/quanta]

[quanta.support]
item 1 
...
item n
[/quanta.support]

Either that or do it on kivio?

Thanks,

Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAR3eTSiV5TqRTAEsRAufzAJ9dTUnDmEF5WIdy4N9j50kkawCKbACfaBcQ
2idIjGPjNMoQwl590WUMcbU=
=Pn6H
-----END PGP SIGNATURE-----