Overhaul of releases/<releasename>/index (Re: how to get more recent translations for important web pages)
[Adding debian-ww to the loop]
Hi,
Holger Wansing <hwansing@mailbox.org> wrote (Sun, 3 Dec 2023 00:08:21 +0100):
> And for usual changings:
> I think we need to much resources (on the English side as well as on
> translator's) for repeating tasks like pages under ../releases.
> Basically, the files under
> ../releases/buster
> ../releases/bullseye
> ../releases/bookworm
> ../releases/trixie
> are nearly the same, but with small differences in codenames, release
> dates and such.
> But nevertheless all those pages need to be touched by translators
> many times over the release cycle (if translators want to keep their
> files up-to-date).
> Even pages for oldstable need translator's time to be up-to-date
> (I just spotted exactly this situation for Bullseye today!)
> And remember: if one changes a page in English, that might imply work for
> dozens of translators!!!
>
>
> I can think about changing the whole mechanism behind these pages, to create
> a basis, which has content for all situations during the whole release
> lifetime, without any need to change that underway:
>
> So, we would create such "template" for English, translators work on
> translating the relevant parts and then they have their template for
> their language as well, and when a new release comes, we just run a
> sed script, which changes the codenames from the stable one to oldstable,
> testing to stable, and so on. The release dates need to be adjusted,
> but with that most of the work should be done.
> Another relevant situation is when LTS period starts or ends for a
> release, but I imagine we can get this done be just changing an entity,
> which is used for all languages, and we are done.
I have a tested and working proposal ready now (here for
../releases/bookworm/index).
It contains six sets of different content, which makes it possible, to
dynamically enable the needed content for the respective situations over
the whole release cycle.
That all is controlled via these six variables:
------------------------------------------------------------------
# Is <releasename>-2 the current release ? (yes/no)
<set-var pre-pre-release-state="no" />
# Is <releasename>-1 the current release ? (yes/no)
<set-var pre-release-state="no" />
# Is <releasename> the current release ? (yes/no)
<set-var release-state="yes" />
# Is <releasename>+1 the current release ? (yes/no)
<set-var post-release-state="no" />
# Security updates discontinued for current release ? (yes/no)
<set-var no-security-state="no" />
# Has LTS period begun for current release ? (yes/no)
<set-var release-lts-state="no" />
------------------------------------------------------------------
Apart from that, I have converted the hardcoded dates for "initial release
of Debian 12.0" and "security updates discontinued for Bookworm" into
tags defined in ./english/template/debian/release_info.wml, so no need to
change the index file, when the time for those change comes, just change
the tag.
I filed this as MR:
https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/944
Holger
--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Reply to: