[kdewebdev-site] Proposed PHP infrastructure

[Chris Hornbaker]

On Thu March 4 2004 18:38, Eric Laffoon wrote:
> 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?

Less data, basically. It's the same reason you don't make 50 versions of the same
.cpp file: too much work and data. Could you imagine maintaining Quanta if you
had to change one little line 50 times? Also, it's seemless. Aiming for the user not
even knowing the site isn't in their native language to begin with.

As for the KDE translators, I wouldn't bother them as they have enough to do.
Willing and wanting Quanta users or some of the people on this list would be far
better.

> 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.

KBabel is simple to learn. I was merely enouraging its usage. You could just open
the file in a text editor. No big deal.

> 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...

You can cut off the infrastructure with a simple .htaccess file. That'll allow code
not using it to run freely. I had to do this with a blog and the results were great:
I didn't even notice that something internal was different from a user's POV.

> 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
> _______________________________________________
> kdewebdev-site mailing list
> kdewebdev-site at mail.kdewebdev.org
> http://mail.kdewebdev.org/mailman/listinfo/kdewebdev-site
> 

-- 
Christopher Hornbaker           
Jabber ID: Jilks at jabber.org     Email: chrishornbaker at earthlink.net
Join the Free State Project!    http://www.freestateproject.org
   "Liberty in Our Lifetime"
Was I helpful? Let me know! http://svcs.affero.net/rm.php?r=Jilks