Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Aug 2012 16:02:11 +0200
From:      Gabor Kovesdan <gabor@FreeBSD.org>
To:        "Simon L. B. Nielsen" <simon@FreeBSD.org>
Cc:        doc@freebsd.org, www@freebsd.org
Subject:   Re: RFC: doc/www cleanup
Message-ID:  <501BD9E3.305@FreeBSD.org>
In-Reply-To: <CAC8HS2E2ekMKJgY04qPrQGbEe_tPJ%2BHrf5_ToERptf0yawYoQA@mail.gmail.com>
References:  <501BAFBD.3010008@FreeBSD.org> <CAC8HS2E2ekMKJgY04qPrQGbEe_tPJ%2BHrf5_ToERptf0yawYoQA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2012.08.03. 15:33, Simon L. B. Nielsen wrote:
> I agree that the entities should generally not be used. I think we
> should just switch to UTF-8 and charecterset wherever possible to
> simplify it even more.
Agreed. UTF-8 is the future but I see it too early. You can now edit 
Latin-based encodings everywhere but I often use ssh terminal and ee(1) 
to edit documentations because I have a build environment and my devel 
stuff set up on a server and I can confirm that editing UTF-8 is 
sometimes problematic.
> To a degree. IMO XSLT is a horrible language to work with unless you
> are really used to it, and I suspect most people aren't compared to
> normal scripting languages.
>
> Using XML as the main format sounds fine with me, but only use XSLT if
> it can be done short and sanely.
These would be very simple and short templates and the whole XSLT stuff 
has been simplified in the sgml2xml branch.
>
> The more relevant part of this to fix IMO, is that both sitemap and
> a-z indexes are horribly out of date / incomplete.
Agreed. But I want to separate infrastructure and content changes.
>
>> 4, Stricter XHML: I don't propose going directly to XHTML Strict 1.0 but
> Eh, why would you go to XHTML at all considering it's basically
> deprecated in favor for HTML5 (yes, there is no standard for that, but
> still..).
I can think of two reasons:
(1) It is the trivial and straight way to go to XHTML for now. HTML5 
would be a bigger jump that should be tested more carefully. The current 
plan is to do the migration in several phases for better QA. For 
example, for now we are only going to DocBook 4.2/XML, which can still 
be used with Jade and DocBook DSSSL. Going to full XML-based standards 
and newer DocBook version will be a next step that requires more testing.
(2) Are you sure HTML5 is supported in all browsers that our users use? 
For example, I sometimes use links and I imagine other people may do so, 
as well. We should investigate this more.
> I agree with that, but do be aware that there might be reasons for it
> being done that at times... Ie, don't blindly convert without checking
> the output.
Of course, I meant doing it with proper testing.
> I personally prefer not killing the redirects if possible, but they
> could be done better at the HTTP level. If you can just generate a
> list of redirects I can move add them at the HTTP layer.
Sounds good but what about mirrors? Maybe we should just generate 
redirection pages with a template and some Makefile macros?
>
>> are leftovers in translations, i.e. pages that were removed from the English
>> web but not from the translations. I would like to generate a list of them
>> and send patches to translation projects to clean these up.
> That also hints at the general problem of stale translated pages,
> which can be much worse than not translated at all.
I agree but I don't want to step on the feet of the translators. They 
should themselves investigate how outdated something is but if something 
was deleted from the English pages, there's definitely no reason to keep 
it in translations, that's why I proposed it in such a way.
>
> Do we ever check how out of date pages are currently?
I think it depends on each translation project. And checking 
"outdatedness" isn't trivial. The revision number doesn't say anything. 
Nor does the number of changes on the original version, since one change 
can be a typo fix or a relevant content update. There's no way to figure 
it out. And checking the modification date is also useless because there 
are generally valid pieces of information and if you commit a typo fix 
after 3 years that doesn't make the translation seriously outdated... So 
I think it can only be done manually. But we could generate a warning if 
there's a newer English version. The Japanese translation used to do 
that but it broke after the SVN migration. We'll check that with hrs@ 
after the XML migration is done.

Gabor



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?501BD9E3.305>