I haven't seen that term yet, maybe one to add to the jargon file :-)
I was thinking, a database-driven glossary would be more useful than a jargon file.
http://bugzilla.mozilla.org/show_bug.cgi?id=202689
What do you think?
Yeah, *a lot* better than the current file/idea. The '&action=Find' parameter is probably redundant and not necessary though. I wonder if it makes sense to redirect it to a form without variable, since it causes some extra server hits (redirects), where /glossery?term=xhtml would work perfectly.
Optimizing the URI structure,
If you're want to tinker with that, *let me know*. I spent over a year chatting with mpt about it, and I'm slowly tweaking things in line with that plan.
That is quite some time. I heard, from mpt, that he stopped with the project.
You asked him about it?
Yeah, about a month ago on the WordPress IRC channel. But maybe he was only talking about his UI contributing part?
There are a lot of things that just seem wrong, a lot of files are in the root directory were it would make more sense to put the in some "category directory" where they belong.
There hasn't really been anyone keeping tabs on the site organization these many years. It's like a big cauldron where everyone dumps things rather than like an organized filing system.
That explains it. Having mozilla.org/bonsai.html, mozilla.org/hacking/bonsai.html and mozilla.org/projects/bonsai/ makes life complicated. It makes it difficult for end users too, where can they find the information they need...
Oh, I certainly agree. The only reason it's not in the Style Guide is that I didn't know how well it would work with our current system. Tell me when you think I should add it in, and if authors need to do anything special (e.g. add a <meta> tag). I'll then check with website-drivers and, if they're ok with it, add it to the Style Guide.
The problem is HTTP controls the character encoding. I'm not sure how mozilla.org handles this, but the most optimal solution would be a
AddDefaultCharset utf-8
... in httpd.conf, but I'm not sure if there is access to that file. Enabling things like multiviews and setting up redirects in that file (and disabling .htaccess) gives the fastest performance possible, I believe.
In the end, you also want to remove the META elements I guess. Especially those with a 'http-equiv' attribute, since those can be controled through HTTP.
Now the only left to do is to make mozilla.org match those documents. A
lot of documents already validate, but their semantics aren't really good.
I think I'm going to file bugs for those to get some discussion going on,
on how to improve those. If solutions are found I'm willing to patch them.
If you get bogged down in review, don't leave the bug. Ask for what you've
got so far to be checked in because it will be an improvement. We can always leave the bug open for further work.
Yeah, I noticed that. I'm quite familiar with it already, although I started contributing patches yesterday :-)
-- Anne van Kesteren <http://annevankesteren.nl/> _______________________________________________ mozilla-documentation mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-documentation
