Re: Getting involved

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