[Women-website] Progress Report

Thierry Reding women-website@lists.alioth.debian.org
Tue, 29 Mar 2005 19:36:46 +0200 

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Jutta Wrage wrote:
> Am Dienstag, 29.03.05 um 07:22 Uhr schrieb Thierry Reding:
>=20
> >The content from the current website has all been ported, with the=20
> >exceptions
> >of the dictionaries and the Wiki.
>=20
> So we have now a webwml tree and a make script?

Yes, we do. The tree can be found on arch.debian.org. Most of the info you
need to check out the source and make modifications can be found here[1].

[...]
> - - What about the script creating the news entries for the main page?

The frontpage is now handled by a blog (blosxom). This has already been
configured to integrate nicely with the website. It is also in the archive.

> - - Is the cvs (or whatever) tree ready installed on alioth?

See above.

> - - Can we do a checkout and try to make a local build? URL?

You can check out the tree by following the instructions on [1]. Making a
local build can be done by running:

    $ make install BASE=3D"http://foobar" DESTDIR=3D"/path/to/htdocs"

BASE is a variable that will be used as a base URL whenever absolute links
are created. This should point to the URL you use to access the local build.
DESTDIR is the destination directory where the files should be installed.
That is the directory you configure your webserver to serve content from
(this is a rather lengthy topic, and out of the scope of this email, so let
me know if you need help with this, I'd be glad to give you a hand).

If all goes well, that should give you a complete build of the current tree.
For content negotiation to work, you'll need to configure your webserver
accordingly of course.

> - - If nothing is on alioth now: Where can we see the source? - For me I=
=20
> have seen only a build.

See above.

> - - Is there a developer instruction manual? (checkout, local build and=
=20
> testing...)

All the documentation I've written for this is on [1], but I'm pretty sure
that it is far from complete. If you have any comments or suggestions, plea=
se
let me know.

> - - Do we already know, who has to have access to the source tree=20
> (checking in changes)?

Everyone in the `women' group on alioth should have access to the archive on
arch.debian.org aswell.

> - - Do we stick to php? There is no advantage any longer, if the pages=20
> are created by webwml.

The current plan is not to stick to PHP anymore, except for the Wiki of
course. The new build system doesn't generate any PHP, only plain XHTML 1.1.

> - - If everything goes xhtml: how is the validation done? How do we=20
> handle the xhtml issues (and there are some with negotiation and mime=20
> type)

Validation is done manually. I've checked all the pages so far, and they all
validate using the W3C Markup Validator[2]. So far I have not encountered a=
ny
problems with content negotiation and XHTML, though it'd be great if you
could let me know about problems you know of.

> - - Who writes a manual page with the differences between html strict and=
=20
> xhtml if everything has to be xhtml? How does the source have to look=20
> like?

My intention is to completely get rid of everything HTML in the sources, and
to only use a couple of custom tags, which will expand to valid XHTML 1.1.
That said, I don't think we can make completely sure that we will never have
to go in and manually fix some invalid code that sneaked it's way into the
tree.

For most of the common HTML tags, an equivalent WML tag has been written. Y=
ou
can find a list of those here[3]. These include <list>, <paragraph>,
<section> etc.

I am not sure whether we need a manual listing the differences between HTML
and XHTML, but if you disagree, maybe you would like to volunteer?

> - - Are we using po files for translations?

Currently not. I do not see any advantages of PO files for webpages.

> - - Who is notified if build does not work and there are errors?

In that case, this list should be notified. I will try and answer any
questions to the best of my knowledge, and I will also try to get some other
people familiar with the build system, so that we do not have to rely on one
person to fix problems. Also, I hope I made it difficult to break the build
system =3D)

> The Wiki has its own history and is to be edited online. That is what a=
=20
> Wiki makes up. No sense to have an extra build source for it.

I agree completely.

> We should have the configuration Data in a versioning tree and - maybe=20
> - - the wiki in a backup tree.

Yes! Exactly.

> The dicts are built from a source by makedictutf8.pl. They do not fit=20
> well in a webwml tree if you do not just put the sources into the main=20
> tree and the build script into the make file.

Note that the build system is rather flexible, so it might still be possible
to get the dicts integrated. I am not very familiar with dict-related stuff,
so you are probably the best person to make this call.

> Could you please tell us what you refer to? how should the scheme be=20
> revised? It is working well for negotiation as far as I have seen.
> Beside that nobody can have an Idea without having seen the webwml=20
> archive.

I was referring to the links to the dictionaries translating from $lang_foo
to $lang_bar. I'm not certain whether the names for those work for content
negotiation. Then again, if you say there's no problem, I'll have to take
your word for it. I haven't had time to test it myself. Thinking about it,
I'm not sure that content negotiation is needed for those anyway, since you
want to be able to choose which languages you want to see the dict in, not
have the server decide based on the preferred language of your browser.

> Currently most of the entries are sent to my by mail and not every time=
=20
> having the correct format and/or encodings. As people from outside=20
> contribute and the web form is running on another server (alioth has no=
=20
> cgiemail installed), I cannnot see an advantage in moving everything to=
=20
> the wml tree.

I disagree. I think it'll help enormously to have it all integrated in one
tree. After all it is part of the same project, isn't it? In particular, the
idea about mirrors jumps to my mind. If the dicts are not integrated into t=
he
website wml tree, then every mirror will need to perform additional steps
when syncing from the original archive.

As for external contributions, I am sure we can find a way to account for
that aswell. As a matter of fact, right now you still need to personally
parse emails and update dict sources in order to make contributions go live,
right? What would be so different having it in the website archive?

> We should discuss that again, if we find a way to have a webmail=20
> interface on alioth. Another isssue is, that the script still cannot=20
> create php pages. I will have to find some time to dive into that. But=20
> if pages are created by webwml and scripts, I cannot see the advantage=20
> of php any longer.

PHP is not needed for the website anymore (except the Wiki).

> Before we make changes to the wiki css, we should discuss about the=20
> general look and feel.
>=20
> There are two issues:
> - - Full accessibility (section 508 and others)

Can you go into more detail about that? I've gone over a checklist of secti=
on
508[4] and as far as I can tell, the Debian Women website does not have any
of those problems. Could you provide some more detailed resources about this
issue?

> - - There was a question about the debian women pages included into the=
=20
> main debian pages. But currently it does look _very_different.=20
> (corporate identity).

So far I have not yet heard that there is consensus about this issue. Could
anybody more knowledgeable comment on this? Do we want this? Are there
actually plans to do that soon? Who do we need to contact? I think that if
this is not going to happen in, say, the next 3 months, it would make sense
to put that aside for now and cross that bridge once we get there.

> Moving things from the Wiki to the main pages should be a seperate=20
> thread. That is a work permanently to be done in the future. But moving=
=20
> the main pages to webwml and revisioning system should not be=20
> complicated by moving things from the wiki to the main pages at the=20
> same time.

As I've said before, the main pages are already ported, nothing more to do
there. Moving Wiki content would not complicate anything, in my opinion.

> As said before: If contributing should be as easy as it is now, there=20
> should not be changes to the source file format of the dictionaries.
> That what can be changed are head and foot files for the page build.
>=20
> Maybe, I should explain the contribute issue a bit more:
> - - The dictionary form creates correct entries already. I only have to=
=20
> look into the encoding then (some deliver an encoding different to that=
=20
> they claim to have delivered).
> - - The format is quite simple now, put I still get wrong format. If the=
=20
> format is changed, that will increase the time needed to update with=20
> contributed translations.

I don't think moving the sources of the dict to the WML tree would make
contributions more difficult. In fact, nothing about the process of
contributing to the dict would need to change. Since you do need to perform
most of the work on that anyway, the only additional step you'd have to do =
is
commit the changes to the archive. Otherwise you could just continue with it
the way you do it now.

> What I still have no idea about is the linking and presentation:
> - - The index page could be included in language negotiation, too. But=20
> what to present in index.en then? all languages? Only the dicts for=20
> that language?

I think the index page is good the way it is. If you were to only show the
negotiated language, a lot of the usefulness of the dictionary would be los=
t.

> - - If all languages in the index.$lang: what about the translations of=
=20
> different language names to others?

I'm not quite sure. Judging by what I've seen on the web, people seem to do
that both ways. I would personally prefer to have each language name
translated into the negotiated language (e.g.: if you look at the English
page, French should show up as "French", while when looking at the French
page, English should show up as "Anglais"). But YMMV.

> - - The debian main pages (which consists of several cvs source trees and=
=20
> their build) have a language switcher at bottom of page. What about=20
> that?

I was thinking about that the other day aswell. I think we should have
something like that too. The main Debian website has one problem though, in
that it doesn't remember the language that you choose from that language ba=
r.
Whenever you click your way to the next page, it will switch back to the
negotiated language.

I have a couple of ideas about how to work around that, which I ran across
while reading the Debian Women mailing list archives. Anja seemed to have h=
ad
this idea already in August last year[5] and posted an interesting link[6]
which uses a system that uses the negotiated language when first accessing
the page, and then goes on to remember the language that you choose from the
language bar.

> greetings
>=20
> Jutta

Thierry


Now, let's see whether I can gather all these links I referred to =3D)

[1]: http://women.alioth.debian.org/website/
[2]: http://validator.w3.org/
[3]: http://women.alioth.debian.org/website/tags/
[4]: http://www.webaim.org/standards/508/checklist
[5]: http://lists.debian.org/debian-women/2004/08/msg00308.html
[6]: http://ddtp.debian.org/new/


--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFCSZIthS8Ykk2Ma9MRAsUfAJ0YWnJ0GRJ7v8iqCwJ+q/YsqErgbACglCuj
JGBzb1QZHE3GqpSmtwD5jUU=
=eq2D
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--