info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
how to get more recent translations for important web pages
0 views
Skip to first unread message
Thomas Lange
Nov 29, 2023, 2:20:04 PM11/29/23
to
Hi all,
I've checked the translations of our main pages. The startpage and the
download page (/distrib). These pages are top 1 and 3 with the
most hits on our web servers. On 2 is /security.
- www.d.org our main web startpage
On Sep 16 I've changed two major things the startpage after some
discussion at DebConf about user experiences with our web pages.
We have 26 translations of our startpage (+ english).
Only 13 have are up to date, so half of them are outdated after 2.5
months.
- www.d.o/distrib our main download page
We have 31 translations. Only 9 have the most recent translation header.
Only 12 have the direct links to the live ISO for several desktops
which was a bigger change on this page. I would define these 12 as
recent enough.
19 translations are not updated since Sep 16 2023 the date when I
started multiple changes on this web page.
Because these are important pages with many hits, I would expect to
have these translation updated in a few weeks, maybe 1-2 weeks.
When should we remove these outdated translations?
What's your oppinion?
--
regards Thomas
I've checked the translations of our main pages. The startpage and the
download page (/distrib). These pages are top 1 and 3 with the
most hits on our web servers. On 2 is /security.
- www.d.org our main web startpage
On Sep 16 I've changed two major things the startpage after some
discussion at DebConf about user experiences with our web pages.
We have 26 translations of our startpage (+ english).
Only 13 have are up to date, so half of them are outdated after 2.5
months.
- www.d.o/distrib our main download page
We have 31 translations. Only 9 have the most recent translation header.
Only 12 have the direct links to the live ISO for several desktops
which was a bigger change on this page. I would define these 12 as
recent enough.
19 translations are not updated since Sep 16 2023 the date when I
started multiple changes on this web page.
Because these are important pages with many hits, I would expect to
have these translation updated in a few weeks, maybe 1-2 weeks.
When should we remove these outdated translations?
What's your oppinion?
--
regards Thomas
Holger Wansing
Dec 2, 2023, 6:10:04 PM12/2/23
to
Hi Thomas,
Thomas Lange <la...@cs.uni-koeln.de> wrote (Wed, 29 Nov 2023 20:13:50 +0100):
> Because these are important pages with many hits, I would expect to
> have these translation updated in a few weeks, maybe 1-2 weeks.
>
> When should we remove these outdated translations?
> What's your oppinion?
I think we cannot focus thus strict on these "main pages".
We have to lift the view and look on the whole field of work.
There are some very active translators and those languages are fine, but
the majority of languages suffer from a lack of manpower IMO (as many teams
in Debian do).
And we are all volunteers; volunteers in difficult times, with an
(apparently) endless sequence of crisis, wars, and all the problems they
implicate.
Even if one might think, that does not affect Debian directly, I think it
affects the amount of work those volunteers can dedicate to Debian work.
Or it can prevent them from Debian work at all, due to technical or
personal reasons.
So, the point is: translator's time might be rare; and you cannot force
them on what pages they work, there might be more effective criteria then
just the number of hits in our statistic.
Another point might be (while this is my personal opinion here !!!):
there are too much commits to English, which only change trivial things
(remove blank lines; fix typos in English; fix wording ...) and the
translations are not synced or cannot be synced by the author of the
English change. And the translations (might) become outdated because of this.
That leaves unnecessary work to translators, or at least they might think
so ("unnecessary") about such changings. And that affects their motivation
and usage of their time.
We probably need to be more careful with changings in English for trivial
reasons.
Now I remember the big overhaul of the website done by Heike Jurzik
(~2 years ago?).
Due to the lack of manpower in the www team, we hired a professional
web designer, doing the changings in full time, which resulted in heavy
changings on the website.
Did anyone think about hiring professional translators, to sync the
translations? I guess not. The amount of changings were way to high for
normal translator's time slots, so they most probably will need years to
catch up with those changings!!!
Or they give up and leave the pages alone...
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.
Most probably it's not that easy as I write it here, I'm aware of that.
It's just a rough idea at the moment.
But I would like to propose this, because IMO it's worse it to better use
translator's time slots.
Sorry Thomas, long story here, and I did not answer on your initial
question yet :-)
I would not vote too strict against the removal of outdated translations,
in fact I did that some years ago for German as well, due to lack of
manpower in the German team.
You don't get applause for such initiative, it's an unthankful job.
That being said, I could imagine a timeframe from ~6 months for this
to be senseful?
On the other hand, it occurred to me, if it's possible, to only change the
filename from let's say index.wml to index.wml.old instead of removing the
file (assuming that the wml build process of the website ignores such
files; did not check that).
That would make it very easy for translators, to catch up with their work,
if they find time.
Of course you might say "Hey, the file is not lost, we have a git repo
here! No need for such trick."
That's of course correct, but translators might not be as familiar with
such advanced usage of git as DDs are.
So I think it would be worse it.
What do you think?
(Should I stop writing here?
Yes, this mail has gone long enough for today :-) )
So long
Holger
--
Holger Wansing <hwan...@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Thomas Lange <la...@cs.uni-koeln.de> wrote (Wed, 29 Nov 2023 20:13:50 +0100):
> Because these are important pages with many hits, I would expect to
> have these translation updated in a few weeks, maybe 1-2 weeks.
>
> When should we remove these outdated translations?
> What's your oppinion?
We have to lift the view and look on the whole field of work.
There are some very active translators and those languages are fine, but
the majority of languages suffer from a lack of manpower IMO (as many teams
in Debian do).
And we are all volunteers; volunteers in difficult times, with an
(apparently) endless sequence of crisis, wars, and all the problems they
implicate.
Even if one might think, that does not affect Debian directly, I think it
affects the amount of work those volunteers can dedicate to Debian work.
Or it can prevent them from Debian work at all, due to technical or
personal reasons.
So, the point is: translator's time might be rare; and you cannot force
them on what pages they work, there might be more effective criteria then
just the number of hits in our statistic.
Another point might be (while this is my personal opinion here !!!):
there are too much commits to English, which only change trivial things
(remove blank lines; fix typos in English; fix wording ...) and the
translations are not synced or cannot be synced by the author of the
English change. And the translations (might) become outdated because of this.
That leaves unnecessary work to translators, or at least they might think
so ("unnecessary") about such changings. And that affects their motivation
and usage of their time.
We probably need to be more careful with changings in English for trivial
reasons.
Now I remember the big overhaul of the website done by Heike Jurzik
(~2 years ago?).
Due to the lack of manpower in the www team, we hired a professional
web designer, doing the changings in full time, which resulted in heavy
changings on the website.
Did anyone think about hiring professional translators, to sync the
translations? I guess not. The amount of changings were way to high for
normal translator's time slots, so they most probably will need years to
catch up with those changings!!!
Or they give up and leave the pages alone...
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.
Most probably it's not that easy as I write it here, I'm aware of that.
It's just a rough idea at the moment.
But I would like to propose this, because IMO it's worse it to better use
translator's time slots.
Sorry Thomas, long story here, and I did not answer on your initial
question yet :-)
I would not vote too strict against the removal of outdated translations,
in fact I did that some years ago for German as well, due to lack of
manpower in the German team.
You don't get applause for such initiative, it's an unthankful job.
That being said, I could imagine a timeframe from ~6 months for this
to be senseful?
On the other hand, it occurred to me, if it's possible, to only change the
filename from let's say index.wml to index.wml.old instead of removing the
file (assuming that the wml build process of the website ignores such
files; did not check that).
That would make it very easy for translators, to catch up with their work,
if they find time.
Of course you might say "Hey, the file is not lost, we have a git repo
here! No need for such trick."
That's of course correct, but translators might not be as familiar with
such advanced usage of git as DDs are.
So I think it would be worse it.
What do you think?
(Should I stop writing here?
Yes, this mail has gone long enough for today :-) )
So long
Holger
--
Holger Wansing <hwan...@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Helge Kreutzmann
Dec 3, 2023, 12:50:03 AM12/3/23
to
Hello,
thanks Holger for rasing these issues.
I only want to reply to a few sub points, but I guess I could write
simmilarly long e-mails.
Am Sun, Dec 03, 2023 at 12:08:21AM +0100 schrieb Holger Wansing:
> Thomas Lange <la...@cs.uni-koeln.de> wrote (Wed, 29 Nov 2023 20:13:50 +0100):
> > Because these are important pages with many hits, I would expect to
> > have these translation updated in a few weeks, maybe 1-2 weeks.
> >
> > When should we remove these outdated translations?
> > What's your oppinion?
noticed a similar pattern there as well - teams focus on different
aspects and by different schedule. So some translators take the "easy"
things first, some work by alphabet, some by some kind of popularity.
From outside, it is hard to tell. And some work seldom, some more
often, but all appear glad to have something to continue work with.
> Another point might be (while this is my personal opinion here !!!):
> there are too much commits to English, which only change trivial things
> (remove blank lines; fix typos in English; fix wording ...) and the
> translations are not synced or cannot be synced by the author of the
> English change. And the translations (might) become outdated because of this.
This is one of the most major PITA for translators. I've seen them
several times in different projects. Oh, we add the Oxford comma. Oh,
we change the quotes. Uups, wrong britsh/US spelling.
While the upstream change might be easily done with a script, each
translator, again and again, has to review the change and then to
determine if (or if not, often) an update is needed. No visibility and
much of redone work by far too few translators. This is time consuming
and demotivating.
So it would be great if people working on the english version could
strictly split their commits. First, doing (if necessary) the english
polishing. Then mark this commit appropriately ("no changes for
translations necessary") and also "sync" all up to date translations.
Seperately from this, work on content, where updates by the
translators are needed.
> I would not vote too strict against the removal of outdated translations,
> in fact I did that some years ago for German as well, due to lack of
> manpower in the German team.
Yes, it was me who was hit. I spend quite some time on translating the
web page but then I did not have the time anymore to maintain it
appropriately. But I always thought the notion "this page is outdate,
you can look here to get the lates version in english" is fine. And
other (potential) translators could easily pick it up. (And if it is
too old, then the english is shown).
> Of course you might say "Hey, the file is not lost, we have a git repo
> here! No need for such trick."
> That's of course correct, but translators might not be as familiar with
> such advanced usage of git as DDs are.
> So I think it would be worse it.
Pointing translators to git, as Holger said, does not work. They
are not programmers. Make it easy for them to discover previous work
and continue it. It might even be work from long ago.
In manpages-l10n we collect those old work and transform them in PO
files. They are there - translators can "easily" spot them and
continue work. If the translation is below 80%, then it will no longer
be built. But I'v been able to recruite many translators who happily
picked up the work. And yes, as (part of) upstream I can often sync
translations myself (e.g. version number changes).
Deleting/Removing is not the right way. It just hurts/demotivates
translators. And I don't think disc space is so much of a concern
nowadays (at least for text). Having a small translation, however,
just gives rise to the chance for some potential translator to say
"Hey, my language is welcome here, but it is not doing good. Maybe I
can contribute!"
Greetings
Helge
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
thanks Holger for rasing these issues.
I only want to reply to a few sub points, but I guess I could write
simmilarly long e-mails.
Am Sun, Dec 03, 2023 at 12:08:21AM +0100 schrieb Holger Wansing:
> Thomas Lange <la...@cs.uni-koeln.de> wrote (Wed, 29 Nov 2023 20:13:50 +0100):
> > Because these are important pages with many hits, I would expect to
> > have these translation updated in a few weeks, maybe 1-2 weeks.
> >
> > When should we remove these outdated translations?
> > What's your oppinion?
> So, the point is: translator's time might be rare; and you cannot force
> them on what pages they work, there might be more effective criteria then
> just the number of hits in our statistic.
I'm heavily involved in translations, e.g. for man pages, and I
> them on what pages they work, there might be more effective criteria then
> just the number of hits in our statistic.
noticed a similar pattern there as well - teams focus on different
aspects and by different schedule. So some translators take the "easy"
things first, some work by alphabet, some by some kind of popularity.
From outside, it is hard to tell. And some work seldom, some more
often, but all appear glad to have something to continue work with.
> Another point might be (while this is my personal opinion here !!!):
> there are too much commits to English, which only change trivial things
> (remove blank lines; fix typos in English; fix wording ...) and the
> translations are not synced or cannot be synced by the author of the
> English change. And the translations (might) become outdated because of this.
several times in different projects. Oh, we add the Oxford comma. Oh,
we change the quotes. Uups, wrong britsh/US spelling.
While the upstream change might be easily done with a script, each
translator, again and again, has to review the change and then to
determine if (or if not, often) an update is needed. No visibility and
much of redone work by far too few translators. This is time consuming
and demotivating.
So it would be great if people working on the english version could
strictly split their commits. First, doing (if necessary) the english
polishing. Then mark this commit appropriately ("no changes for
translations necessary") and also "sync" all up to date translations.
Seperately from this, work on content, where updates by the
translators are needed.
> I would not vote too strict against the removal of outdated translations,
> in fact I did that some years ago for German as well, due to lack of
> manpower in the German team.
web page but then I did not have the time anymore to maintain it
appropriately. But I always thought the notion "this page is outdate,
you can look here to get the lates version in english" is fine. And
other (potential) translators could easily pick it up. (And if it is
too old, then the english is shown).
> Of course you might say "Hey, the file is not lost, we have a git repo
> here! No need for such trick."
> That's of course correct, but translators might not be as familiar with
> such advanced usage of git as DDs are.
> So I think it would be worse it.
are not programmers. Make it easy for them to discover previous work
and continue it. It might even be work from long ago.
In manpages-l10n we collect those old work and transform them in PO
files. They are there - translators can "easily" spot them and
continue work. If the translation is below 80%, then it will no longer
be built. But I'v been able to recruite many translators who happily
picked up the work. And yes, as (part of) upstream I can often sync
translations myself (e.g. version number changes).
Deleting/Removing is not the right way. It just hurts/demotivates
translators. And I don't think disc space is so much of a concern
nowadays (at least for text). Having a small translation, however,
just gives rise to the chance for some potential translator to say
"Hey, my language is welcome here, but it is not doing good. Maybe I
can contribute!"
Greetings
Helge
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Marc Haber
Dec 3, 2023, 5:30:04 AM12/3/23
to
On Wed, Nov 29, 2023 at 08:13:50PM +0100, Thomas Lange wrote:
> When should we remove these outdated translations?
> What's your oppinion?
I am neither a translator nor am I involved too much with i18n, but
> When should we remove these outdated translations?
> What's your oppinion?
personally, I'd rather have current English docs than outdated docs in
other languages. There is not much that is more anoying than outdated
docs.
If we're reasonably honest to ourselves, noone is going to get far in
Debian without at least basic knowledge of English, so I'd rather have
the web server deliver a current English page than a translated page
that shows content that has been superseded in Debian's native language
for weeks.
How does, for example, /security work? Will the German page show
today's DSA automatically?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Marc Haber
Dec 3, 2023, 5:30:05 AM12/3/23
to
On Sun, Dec 03, 2023 at 05:48:13AM +0000, Helge Kreutzmann wrote:
> So it would be great if people working on the english version could
> strictly split their commits. First, doing (if necessary) the english
> polishing. Then mark this commit appropriately ("no changes for
> translations necessary") and also "sync" all up to date translations.
Are there tools that can be used to automate the syncing of up to date
> So it would be great if people working on the english version could
> strictly split their commits. First, doing (if necessary) the english
> polishing. Then mark this commit appropriately ("no changes for
> translations necessary") and also "sync" all up to date translations.
translations? I must admit that I have held back changes to English text
to save myself from this tedious, busy work.
Thomas Lange
Dec 3, 2023, 8:20:03 AM12/3/23
to
>>>>> On Sun, 3 Dec 2023 11:19:51 +0100, Marc Haber <mh+debi...@zugschlus.de> said:
> How does, for example, /security work? Will the German page show
> today's DSA automatically?
Yes, the list of DSA (or DLA) are generated automatically
> How does, for example, /security work? Will the German page show
> today's DSA automatically?
and the list is then included for every language.
But the note on the top (about outdated translation) may be confusing
to our users, because we do not say which part(s) or how much of the
web pages are outdated. For the security pages it means that only some
parts of the text is outdated but not the list of security
announcements. But that's not clear to our readers.
This is a common problem. Even if we only do a small change (e.g. http
to https), the translated pages may say "hey, use the english version,
because I'm not up-to-date." That's anoying and I guess after you hit
this situation several times, you will stuck on reading the english
version if it's possible for you.
--
regards Thomas
Helge Kreutzmann
Dec 3, 2023, 12:50:04 PM12/3/23
to
Hello,
current translated content as present.
> This is a common problem. Even if we only do a small change (e.g. http
> to https), the translated pages may say "hey, use the english version,
> because I'm not up-to-date." That's anoying and I guess after you hit
> this situation several times, you will stuck on reading the english
> version if it's possible for you.
And possibly having a hard time to.
We try to be inclusive ("universal operating system") so we should
look for solutions instead of dropping a significant portion of
(potential) users. So work on the tooling.
At least I (manpages-l10n) strive hard to have as many current
translations as possible, so users are able to read most of the page
in their langauge, even if the explantion for the latest option is not
yet translated (but they might be satisfied with the rest).
Make it easy for the (few) translators and present as much as possible
translated.
For mostly static text this is much easier than for highly dynamic,
that is of course true.
Am Sun, Dec 03, 2023 at 02:18:44PM +0100 schrieb Thomas Lange:
> >>>>> On Sun, 3 Dec 2023 11:19:51 +0100, Marc Haber <mh+debi...@zugschlus.de> said:
>
> > How does, for example, /security work? Will the German page show
> > today's DSA automatically?
> Yes, the list of DSA (or DLA) are generated automatically
> and the list is then included for every language.
>
> But the note on the top (about outdated translation) may be confusing
> to our users, because we do not say which part(s) or how much of the
> web pages are outdated. For the security pages it means that only some
> parts of the text is outdated but not the list of security
> announcements. But that's not clear to our readers.
Then we should make this clearer, and if possible include as much
> >>>>> On Sun, 3 Dec 2023 11:19:51 +0100, Marc Haber <mh+debi...@zugschlus.de> said:
>
> > How does, for example, /security work? Will the German page show
> > today's DSA automatically?
> Yes, the list of DSA (or DLA) are generated automatically
> and the list is then included for every language.
>
> But the note on the top (about outdated translation) may be confusing
> to our users, because we do not say which part(s) or how much of the
> web pages are outdated. For the security pages it means that only some
> parts of the text is outdated but not the list of security
> announcements. But that's not clear to our readers.
current translated content as present.
> This is a common problem. Even if we only do a small change (e.g. http
> to https), the translated pages may say "hey, use the english version,
> because I'm not up-to-date." That's anoying and I guess after you hit
> this situation several times, you will stuck on reading the english
> version if it's possible for you.
We try to be inclusive ("universal operating system") so we should
look for solutions instead of dropping a significant portion of
(potential) users. So work on the tooling.
At least I (manpages-l10n) strive hard to have as many current
translations as possible, so users are able to read most of the page
in their langauge, even if the explantion for the latest option is not
yet translated (but they might be satisfied with the rest).
Make it easy for the (few) translators and present as much as possible
translated.
For mostly static text this is much easier than for highly dynamic,
that is of course true.
Holger Wansing
Dec 3, 2023, 1:30:06 PM12/3/23
to
Hi,
Am 3. Dezember 2023 18:48:18 MEZ schrieb Helge Kreutzmann <deb...@helgefjell.de>:
>At least I (manpages-l10n) strive hard to have as many current
>translations as possible, so users are able to read most of the page
>in their langauge, even if the explantion for the latest option is not
>yet translated (but they might be satisfied with the rest).
>
>Make it easy for the (few) translators and present as much as possible
>translated.
>
>For mostly static text this is much easier than for highly dynamic,
>that is of course true.
You know, that you cannot compare manpages with the website:
the manpages are po based, and therefore you can have parts untranslated,
but the rest visible in German.
And you can not have outdated content: changed parts are marked as fuzzy and
therefore fall back to English.
The website is build of wml files, one file per page (in the very most cases),
so the page is either up-to-date, or you get the warning banner.
Holger
--
Sent from /e/ OS on Fairphone3
Am 3. Dezember 2023 18:48:18 MEZ schrieb Helge Kreutzmann <deb...@helgefjell.de>:
>At least I (manpages-l10n) strive hard to have as many current
>translations as possible, so users are able to read most of the page
>in their langauge, even if the explantion for the latest option is not
>yet translated (but they might be satisfied with the rest).
>
>Make it easy for the (few) translators and present as much as possible
>translated.
>
>For mostly static text this is much easier than for highly dynamic,
>that is of course true.
the manpages are po based, and therefore you can have parts untranslated,
but the rest visible in German.
And you can not have outdated content: changed parts are marked as fuzzy and
therefore fall back to English.
The website is build of wml files, one file per page (in the very most cases),
so the page is either up-to-date, or you get the warning banner.
Holger
--
Sent from /e/ OS on Fairphone3
Holger Wansing
Dec 6, 2023, 4:20:04 PM12/6/23
to
[Adding debian-ww to the loop]
Hi,
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
Hi,
../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 Wansing
Dec 7, 2023, 3:00:04 PM12/7/23
to
[Adding debian-www to the loop]
renamed that into installmanual.outdated and that works, the page gets
removed from the web, and otherwise no errors on the webwml build.
So, maybe that would be a possible "solution", instead of removing the
translation files completely?
> I would not vote too strict against the removal of outdated translations,
> in fact I did that some years ago for German as well, due to lack of
> manpower in the German team.
> You don't get applause for such initiative, it's an unthankful job.
>
> That being said, I could imagine a timeframe from ~6 months for this
> to be senseful?
>
> On the other hand, it occurred to me, if it's possible, to only change the
> filename from let's say index.wml to index.wml.old instead of removing the
> file (assuming that the wml build process of the website ignores such
> files; did not check that).
> That would make it very easy for translators, to catch up with their work,
> if they find time.
> Of course you might say "Hey, the file is not lost, we have a git repo
> here! No need for such trick."
> That's of course correct, but translators might not be as familiar with
> such advanced usage of git as DDs are.
> So I think it would be worse it.
I have tested this for ../german/releases/trixie/installmanual.wml,
> in fact I did that some years ago for German as well, due to lack of
> manpower in the German team.
> You don't get applause for such initiative, it's an unthankful job.
>
> That being said, I could imagine a timeframe from ~6 months for this
> to be senseful?
>
> On the other hand, it occurred to me, if it's possible, to only change the
> filename from let's say index.wml to index.wml.old instead of removing the
> file (assuming that the wml build process of the website ignores such
> files; did not check that).
> That would make it very easy for translators, to catch up with their work,
> if they find time.
> Of course you might say "Hey, the file is not lost, we have a git repo
> here! No need for such trick."
> That's of course correct, but translators might not be as familiar with
> such advanced usage of git as DDs are.
> So I think it would be worse it.
renamed that into installmanual.outdated and that works, the page gets
removed from the web, and otherwise no errors on the webwml build.
So, maybe that would be a possible "solution", instead of removing the
translation files completely?
Thomas Lange
Dec 8, 2023, 4:40:04 AM12/8/23
to
>>>>> On Thu, 7 Dec 2023 20:59:08 +0100, Holger Wansing <hwan...@mailbox.org> said:
> [Adding debian-www to the loop]
> Hi,
> [Adding debian-www to the loop]
> Hi,
>> On the other hand, it occurred to me, if it's possible, to only change the
>> filename from let's say index.wml to index.wml.old instead of removing the
>> file (assuming that the wml build process of the website ignores such
>> files; did not check that).
>> That would make it very easy for translators, to catch up with their work,
>> if they find time.
>> Of course you might say "Hey, the file is not lost, we have a git repo
>> here! No need for such trick."
>> That's of course correct, but translators might not be as familiar with
>> such advanced usage of git as DDs are.
>> So I think it would be worse it.
The only advantage I see, is that you see that there's an old
>> filename from let's say index.wml to index.wml.old instead of removing the
>> file (assuming that the wml build process of the website ignores such
>> files; did not check that).
>> That would make it very easy for translators, to catch up with their work,
>> if they find time.
>> Of course you might say "Hey, the file is not lost, we have a git repo
>> here! No need for such trick."
>> That's of course correct, but translators might not be as familiar with
>> such advanced usage of git as DDs are.
>> So I think it would be worse it.
translation, for those were we will catch up with the renaming. In the
end the translators always have to use git. Having an .outdated file they need to use
$ git mv xxx.outdated xxxx
I we delete the file they could use a simple 2-line shell script we
provide for them:
#! /bin/bash
hash=$(git log -- $1|head -1|awk '{print $2 "~1" }')
git checkout $hash -- $1
Let's call it undo-delete <filename>
> I have tested this for ../german/releases/trixie/installmanual.wml,
> renamed that into installmanual.outdated and that works, the page gets
> removed from the web, and otherwise no errors on the webwml build.
> So, maybe that would be a possible "solution", instead of removing the
> translation files completely?
files. Otherwise the translators could never rely on seeing a
.outdated file. What if there's no .outdated? Then they have to parse through the git
log and check if there's nevertheless an old deleted translation.
One more point: Does thi work for a complete deleted subdirectory, as I did
some time ago with tamil, albanian,...
I'm not against your solution and I think we should give it a try and
then after a year see if this helps to get more recent
translations. Then we can made a new decision if we want continue this workflow.
--
viele Grüße Thomas
0 new messages