trans-coord-devel
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: home.shtml: Make checks whether the HTML is decently generated.

From: Kaloian Doganov
Subject: Re: home.shtml: Make checks whether the HTML is decently generated.
Date: Tue, 05 Feb 2008 16:19:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gNewSense gnu/linux) 
Yavor Doganov <address@hidden> writes:

    1) You should modify it to operate from prep/gnun, like
    make-prototype.

Hm, I'm running it exactly in this directory, next to make-prototype.  I
doubt it will work outside prep/gnun without modifications.  Do you have
any problems running it in prep/gnun?

    2) Requires (naturally) header.xx.html and footer.xx.html to be
       under under /server.  We can just amend the sync rule to copy
       them for those languages that are necessary, without keeping them
       in CVS (there will be no problem at all when GNUN operates in
       www).

I agree.  This could be done by addig the additional filenames to
`files_to_sync' but not to `template_files'.  I may be useful to
describe those filenames in a new variable, for example
`verb(atim)_templates'.  Also we could add the additional files to
gnun's repository to keep it self-contained.

Another, completely different approach is to provide static dummy
include files (such as header.xx.html and footer.xx.html) with minimal
content (such as just "</head><body>" in banner.xx.html) and placed at a
appropriately named directory.  Then use those dummy include files to
expand `#include' directives in articles and validate the resulting
output.  This will isolate article validation from rest of the site.
So, if someone tweaks and breaks server/banner.html by accident, the
articles will still validate.  This has drawbacks too, of course, and I
tend to prefer the current approach -- expansion with real templates.
       
    3) We can then introduce error-checking, for example VALIDATE=yes
       for msgfmt checks plus XHTML-validity for the originals, and
       VALIDATE=hard to validate the generated translations.  Just an
       idea, the variable name(s) and values/behaviour will be
       discussed.

Why we would need to split the validation of generated translations from
the validation of their sources?  E.g. why not just have
VALIDATE=(yes|no)?

    > w3c-dtd-xhtml):

    This is missing, but I could copy the files in $HOME.  I'm not sure
    if xmllint will find everything (and what options except --path are
    necessary), though.

Without w3c-dtd-xhtml package installed, xmllint tries to fetch DTDs by
their public URLs (from W3C website) and uses them on the fly.  This
works, but I do not like it, since it generates HTTP traffic for every
single xmllint invocation and may be a security hole (exploited by using
specially forged DTDs).  It's much better if those DTD files are
installed locally.

Unfortunately, I didn't managed to make xmllint work completely offline
from given --path without system-wide DTD catalogs, provided by
w3c-dtd-xhtml package.  (When testing this by yourself, be sure to
specify `--nocatalogs' and `--nonet' options to xmllint.)

    It would be excellent if we perform all these checks at build time
    -- one day gnu.org will be 100% valid (Foo)HTML without extra
    effort.

Yes, such automatic validation will enable us to catch errors as early
as possible and help us achieve this goal.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]