Re: [Tikiwiki-devel] Accessibility, Themes, Icons, and Translations (part I)

[Damian P. <da...@da...>]

Brian Todoroff wrote:
> Damian,
> 
> Yea, we have been overlapping a bit.   Hope I'm not stepping on your toes,
> but musus was eager, I was interested, and you seem to have a million
> demands on your time already.
> 
> musus and I discussed the alt tag wording and icon uploads a fair amount
> over the last week and came to the conclusion that the DB load that it would
> take to support it was not really worth it.  The reasoning was many fold but
> includes:
> 
> -Most users (vs. admins) who are going to rely on alt tags will need good
> alt tags to even use the site in the first place. They will be unlikely to
> enjoy the experience of a site with such poor alt tags that they need to set
> them themselves and just won't use it.  Even if they have the ability to set
> the tags, they will need good tags in place to navigate the feature that
> sets those tags. (A bit of a catch 22 :) )  Therefore the templates will
> need to have good, translatable ({tr}{/tr}), alt tags to start with. We've
> been brainstorming good ways to allow the admin to change these without
> touching the templates.  The best we've come up with so far is possibly
> giving them a web interface to edit a local translation file for the tags,
> but neither of us know enough about the tr nuts and bolts to evaluate that
> option yet.

Ok, take the view of site admin tho.  They will always be able to tweak 
a template. Especially when creating their sites theme.  A heavy modded 
style would probably break the alt tags anyway.  I think as I was 
talking to Marc earlier. we have to aim for a single 508 theme (musus 
theme) and then derive other works from that.

> 
> -We already use too many DB lookups to render pages (180 queries just for
> the home page of tw.o)

Im useing a cache layer.  If you make changes in the database table it 
then updates the php cache file.  It only uses the db table to store the 
contents of the cache in a editable and managable format. :)  No 
additional database queries are performed in rendering a page.  When you 
make a change it updates the db and remakes the cache file.  The db 
performanance was one of my concerns

> 
> -Very few users in the general public (tw devs are not general public ;-) )
> want to create their own icons for a site.  Admins will want to, but they do
> not need to upload them through the web page.  While a cool feature in
> theory, as Rick found out the other day, its much better to simply log into
> the server and ftp the lot of them at once.

True. however, as a TikiWiki hosting provider, I got feedback from my 
clients who wanted a web interface, so thats what they got :) My admins 
are not computer people, but TikiWiki has given them the ability to have 
their own webspace without the need for knowledge of FTP etc.

> 
> I'm interested to hear more about the TikiPartener issues you raise.  That
> is a new issue to me and agree that it would be better not to break
> something popular or at least to find a way to build in compatibility.  I'll
> poke around and see what I can learn, but please do share what you can with
> me.
> 

The big concern here is if we start modifing these locations and other 
projects code, we would need to maintain a copy of those projects and 
the upgrade process would become nightmare

> Thanks and keep the good input coming,
> Brian
> 

Damian
TikiWiki
http://tikiwiki.org
http://tikigod.org