Bug#912724: www.debian.org: wrong links to translations of "Debian Developer's Reference"
Package: www.debian.org Severity: normal Tags: l10n Dear Maintainer, Debian Developer's Reference on the Debian's website [reference] contains wrong links to translations of the documantation. That is, French translation is linked as index.fr.en.html (where it should be index.fr.html) and so on. The same problem holds for translations, that is French translation [reference-fr] links to Italian as index.it.fr.html (where it should be index.it.html). [reference-en] https://www.debian.org/doc/manuals/developers-reference/index.en.html [reference-fr] https://www.debian.org/doc/manuals/developers-reference/index.fr.html I guess the problem is with the content negotiation, since there's no such problems both in the source code of the documentation and in the documentation provided in the package developers-reference (and its translations). It may be possible that content negotiation breaks some other links to translated documentation in the same way. With regards, Lev -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Broken links in developers-reference as published on the Debian's website
Hi Holger,
thanks for your attention to the bug report, but my report was about a
different issue. Let me explain.
First, let's take a look at developers-reference as it pubished on the
Debian's website. Say, in English [web-en]. It incorrectly links to
translations as index.{fr,de,it,ru,jp}.en.html, such files do not exist.
Any other translation, say, French [web-fr] links to translations as
index.{de,it,ru,jp}.fr.html, such files do not exist.
[web-en] https://www.debian.org/doc/manuals/developers-reference/index.en.html
[web-fr] https://www.debian.org/doc/manuals/developers-reference/index.fr.html
Second, let's take a look at developers-reference package. All links
there are correct, that is in _any_ language links point to
index.{fr,de,it,ru,jp}.html.
Third, let's take a look at developers-reference source code. In English
we currently have as follows:
If you want to print this reference, you should use the pdf version. This page is also
available in French, German, Italian, Russian, and Japanese.
Again, links are correct and point to index.{fr,de,it,ru,jp}.html. And
the same holds for any translation.
Broken links are only in developers-reference published on the Debian's
website. Since links in the source code and in the developers-reference
package are correct, then it is the content negotiation problem. Looks
like the webserver incorrectly rewrites links.
Let me stress that my report is _not_ about links to English, or links
in English. It is about _broken_ links in _any_ developers-reference as
published on the Debian's website. So, my bug report is about
www.debian.org, not developers-reference. Please, reconsider it and
reassign #912724 to www.debian.org.
Regards,
Lev
Bug#912724: Broken links in developers-reference as published on the Debian's website
Вс 04 ноя 2018 @ 12:00 Holger Wansing : > Proposal: maybe the easiest way to make all variants (view via debian.org > and opened locally) work correctly, would be to change it this way: > > "This page is also available in > https://www.debian.org/doc/devel-manuals#devref";>French, German, > Italian, Russian, and Japanese." > > since the links on that page are fine and can be linked from everywhere > with one single static link. > Of course, there are still some corner cases which do not work (for example, > when you have the packages installed locally, you cannot switch from the > local english to the local german version via that links, and when you > have no internet connection, you also get an irritating situation), but most > usecases should be fine, and it would be an improvement compared to the > current situation, where all links do not work! > > Would fix #690750 and #912724. > > Comments? In case one take a look into other documentation (togather with its translation), one will not find any such notes and links to translations. Maybe there's no need in such note in "Debian Developer's Reference"? Or at least no need in explicit links? What about to remove it completely or change text to something like "This documentation is also available in some other languages"? Regards, Lev
Bug#912724: Broken links in developers-reference as published on the Debian's website
Пт 16 ноя 2018 @ 20:07 Holger Wansing : > Control: tags -1 + pending > > Lev Lamberov wrote: >> Вс 04 ноя 2018 @ 12:00 Holger Wansing : >> >> > Proposal: maybe the easiest way to make all variants (view via debian.org >> > and opened locally) work correctly, would be to change it this way: >> > >> > "This page is also available in >> > https://www.debian.org/doc/devel-manuals#devref";>French, >> > German, >> > Italian, Russian, and Japanese." >> > >> > since the links on that page are fine and can be linked from everywhere >> > with one single static link. >> > Of course, there are still some corner cases which do not work (for >> > example, >> > when you have the packages installed locally, you cannot switch from the >> > local english to the local german version via that links, and when you >> > have no internet connection, you also get an irritating situation), but >> > most >> > usecases should be fine, and it would be an improvement compared to the >> > current situation, where all links do not work! >> > >> > Would fix #690750 and #912724. >> > >> > Comments? >> >> In case one take a look into other documentation (togather with its >> translation), one will not find any such notes and links to >> translations. Maybe there's no need in such note in "Debian Developer's >> Reference"? Or at least no need in explicit links? What about to remove >> it completely or change text to something like "This documentation is >> also available in some other languages"? > > I have committed this now like this, while 'some other languages' is a link > to https://www.debian.org/doc/devel-manuals#devref Thanks, Holger! Looks like this is the best option for now. Maybe better variant will come later. Cheers! Lev
Bug#859123: automating process for publishing DLAs on the website
Hi, Пн 19 ноя 2018 @ 19:07 Antoine Beaupré : > Few of you might already know that DLAs are *supposed* to show up in > there as well, and did for a while. For example, here's a few DLAs in > 2014: > > https://www.debian.org/security/2014/ > > The process broke down a while back, and reasons don't matter. We need > to figure out how to fix this. > > So I opened #859122 to import the missing DLAs and I've made good > progress. > > But I've opened this bug report (#859123) to fix the process. So far, > the idea we had was to make LTS contributors submit a patch to the > website as part of the DLA publication process. You'd run the little > "parse-dla.pl" script which would create two files in the webwml git > repository, separate from the security tracker! that's where the > debian.org website lives.. Then you'd commit those and send a merge > request to the project (or just push if you have the rights). The > webmaster folks seemed to be open to grant us access to the repo to > remove friction as well.. > > How does that sound? > > Another thing I thought we could do would be to hook that script into a > mailbox that would receive mail from the debian-lts-announce list and > automatically publish the results into git. But so far my efforts at > automating things on Debian infrastructure have mostly failed, so I'm > not sure it's the way to go. Besides, the parse-dsa.pl script isn't > exactly solid, and don't like the idea of parsing arbitrary input like > this without a human oversight. But it would certainly reduce friction > to a minimum, which I like. > > Any other ideas? DSAs are also imported by hand with the help of "parse-advisory.pl", there are always some folks in webwml or security team who can do this. The difference between DSAs and DLAs is that the former is somewhat standartized and can be parsed semi-automatically. It is not always the case with the latter, that is the mentioned "parse-dla.pl" may just throw an error because of some unusual markup or something. But let me stress that even in case of DSAs parsing does not always performs well, and adding a new DSA to the webwml requires checking it beforehand and sometimes fixing html/wml tags. I hope that LTS team _together_ with the Debian Security team will be able to find a common concise markup format which will become a standard both for DSAs and DLAs, and which could be easily and unambiguously parsed, so automatic processing would be possible. Regards, Lev
Bug#929389: patch to fix #929389
Hi,
please find attached a trivial patch to fix #929389.
Cheers!
Lev Lamberov
===File
/home/dogsleg/path/to/cron/parts/0001-7doc-Install-yaml-files.-Closes-929389.patch===
>From e3edaebe4de5efb24993cb8e2e7634ced15a4c42 Mon Sep 17 00:00:00 2001
From: Lev Lamberov
Date: Thu, 30 Apr 2020 13:53:57 +0500
Subject: [PATCH] [7doc] Install yaml files. Closes: #929389
---
parts/7doc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parts/7doc b/parts/7doc
index be23353..2eb9906 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -57,7 +57,7 @@ else # NO ADD
lang0=""
fi
-for ext in epub pdf txt text ps; do
+for ext in epub pdf txt text yaml ps; do
sourcepath=$basedir/${namedoc}${lang0}.$ext
if [ -f "`readlink -f $sourcepath.gz`" ]; then
rm -f $sourcepath
--
2.26.2
Wrong behavior of language-change bar on stats webpages for Debian website
Hello, on English stats webpages for Debian website other available languages are not shown. Also on corresponding translated webpages available translations are shown incorrectly. For example, there's no language-change bar on https://www.debian.org/devel/website/stats/ru.en.html, but on https://www.debian.org/devel/website/stats/ru.ru.html only English is shown (despite this page is available in French, German, and so on...). And the same is for just any language. So, it makes translation of stats.pot and puting a Makefile into devel/website/stats simply useless. I'm not sure what the problem is, so I cannot fix it, sorry. Please, take a look. Cheers! Lev Lamberov
Link to VCS-interface for Debian Developer's Reference
Hello, It would be great if someone could change a link on www.debian.org/doc/devel-manuals for Debian Developer's Reference VCS. Now Subversion contains only file MOVED-TO-GIT. Correct link should be (as I understand) as follows: VCS-interface: git clone http://anonscm.debian.org/gitweb/?p=collab-maint/developers-reference.git It would be great if someone will use smart_change.pl to change the link in other languages too. Cheers! Lev Lamberov
Re: Link to VCS-interface for Debian Developer's Reference
> > VCS-interface: git clone > http://anonscm.debian.org/gitweb/?p=collab-maint/developers-reference.git > Sorry, Web interface: http://anonscm.debian.org/gitweb/?p=collab-maint/developers-reference.git VCS interface: git clone git:// anonscm.debian.org/collab-maint/developers-reference.git
Mistaken version bump
Hello! I've found out that with last update of english/mirror/size.wml version in translated pages was bumped (with help of smart_change.pl?) wrongly (from 1.43 to 1.54, but original English file is 1.44): $ cvs diff -kk -u -r 1.10 -r 1.11 russian/mirror/size.wml Index: russian/mirror/size.wml === RCS file: /cvs/webwml/webwml/russian/mirror/size.wml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- russian/mirror/size.wml 29 Apr 2014 12:47:32 - 1.10 +++ russian/mirror/size.wml 31 Aug 2014 15:01:49 - 1.11 @@ -1,5 +1,5 @@ #use wml::debian::template title="Размер зеркала" -#use wml::debian::translation-check translation="1.43" maintainer="Lev Lamberov" +#use wml::debian::translation-check translation="1.54" maintainer="Lev Lamberov" Каков размер архива Debian? @@ -50,7 +50,7 @@ Каков размер архива Debian Security? -Архив debian-security имеет размер около 44 ГБ. +Архив debian-security имеет размер около 54 ГБ. Каков размер архива Debian Backports? As smart_change.pl was used, so seems that version was bumped wrongly in all translations. I could fix it for Russian, but other translations still should be fixed, and I don't know how to use smart_change.pl, and would like not to use it, because would not like to destroy something accidentally ;-). Cheers! Lev Lamberov
Fwd: Validation failed
Hello, russian l10n team receives the forwarding message, but, as I can see, this translation (russian translation of News/2014/20140831.wml) has no tag-wise difference with english original. Also, I've noticed that english original and all other translations was build succesfully, that is one can reach the corresponding page with explicit https://www.debian.org/News/2014/20140831, but there's still no link to that news entry from the main page. Cheers! Lev Lamberov -- Forwarded message -- From: Debian Webmaster Date: 2014-09-06 19:00 GMT+02:00 Subject: Validation failed To: Yuri Kozlov *** Errors validating /srv/www.debian.org/www/News/2014/20140831.ru.html: *** Line 50, character 25: element "RELEASE_DATE" undefined Line 50, character 34: end tag for "RELEASE_DATE" omitted, but its declaration does not permit this -- You received this mail for the language code ru. Please edit webwml/english/devel/website/validation.data if this is not accurate Please also update webwml/english/devel/website/ with the new coordinator(s) data -- To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xqjlz-00047g...@wolkenstein.debian.org
Fwd: Validation failed
Hello! debian-l10n-russian mailing list receives the forwarded message (see below) since the end of April. The last change in russian/devel/people.wml was done on 30th June 2011. It includes english/devel/people.names, which, as I understand, is generated automatically. So I guess that there's some error in the process of people.names generation or clash between some features of Russian l10n and the process. Could someone check and correct it, please? Cheers! Lev Lamberov -- Forwarded message -- From: Debian Webmaster Date: 2015-05-11 20:27 GMT+05:00 Subject: Validation failed To: Yuri Kozlov *** Errors validating /srv/www.debian.org/www/devel/people.ru.html: *** Line 425, character 240: character "@" not allowed in attribute specification list Line 425, character 240: element "PKG-GNOME-MAINTAINERS" undefined Line 425, character 296: character "@" not allowed in attribute specification list Line 425, character 296: element "POCHU" undefined Line 425, character 333: end tag for "POCHU" omitted, but its declaration does not permit this Line 425, character 333: end tag for "PKG-GNOME-MAINTAINERS" omitted, but its declaration does not permit this -- You received this mail for the language code ru. Please edit webwml/english/devel/website/validation.data if this is not accurate Please also update webwml/english/devel/website/ with the new coordinator(s) data -- To UNSUBSCRIBE, email to debian-l10n-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yrpbm-0004lq...@wolkenstein.debian.org
Re: Validation failed
12 мая 2015 г. 11:04 пользователь "Paul Wise" написал: > > I've cleaned up info for obsolete architectures and that seems to have > fixed the issue. So there was a problem in the apt meta-data for > obsolete architectures that caused the generator to do the wrong > thing. I didn't think to save the data to find out why though. The > next run won't have the validation errors though. Ah, very interesting. Thanks, Paul! Cheers! Lev
Re: Validation failed
2015-05-12 11:04 GMT+05:00 Paul Wise : > On Tue, May 12, 2015 at 1:48 PM, Paul Wise wrote: > > > I've taken a look but I can't reproduce it on my laptop nor in my > > $HOME on the website build server, yet it does occur in the normal > > website build dir on the website build server. > > I've cleaned up info for obsolete architectures and that seems to have > fixed the issue. So there was a problem in the apt meta-data for > obsolete architectures that caused the generator to do the wrong > thing. I didn't think to save the data to find out why though. The > next run won't have the validation errors though. Hmm, seems the problem is still there, look: *** /srv/www.debian.org/www/devel/people.ru.html line 1418 column 13 - Warning: cannot copy name attribute to id *** /srv/www.debian.org/www/women/profiles/template.ru.html line 58 column 1 - Warning: trimming empty line 61 column 1 - Warning: trimming empty line 64 column 1 - Warning: trimming empty line 67 column 1 - Warning: trimming empty line 70 column 1 - Warning: trimming empty line 73 column 1 - Warning: trimming empty line 76 column 1 - Warning: trimming empty Cheers! Lev
Re: Validation failed
2015-05-13 23:21 GMT+05:00 Holger Wansing : > > *** /srv/www.debian.org/www/women/profiles/template.ru.html > > line 58 column 1 - Warning: trimming empty > > line 61 column 1 - Warning: trimming empty > > line 64 column 1 - Warning: trimming empty > > line 67 column 1 - Warning: trimming empty > > line 70 column 1 - Warning: trimming empty > > line 73 column 1 - Warning: trimming empty > > line 76 column 1 - Warning: trimming empty > > The above is indeed another file! > Sure, but I should point that that problem appeared only after previous fix for people.names. The last and only commit of russian/women/profiles/template.wml was on 24th April 2015. Maybe build error log is truncated when it exceeds some value? If yes, I don't think that it's a good idea (seems it is truncated too early). Or maybe check stopped because of error caused by people.names? Cheers! Lev
Validation log and navbar.inc problem
Hi, seems something is wrong with building Russian translation of Debian Hamradio webpages. Validation log for Russian is: *** Errors validating /srv/www.debian.org/www/devel/hamradio/index.ru.html: > *** > Line 48, character 48:document type does not allow element "LINK" here > Line 49, character 23:document type does not allow element "STYLE" > here > Line 106, character 121: end tag for "A" omitted, but its declaration does > not permit this > > But Russian index.wml has the same structure as English. Moreover, I cannot build Russian translation locally without explicitely copying navbar.inc from English. Therefore, I guess there's still an old version of index.ru.html on the website (no new *fixed* builds of Russian index.wml). So, how to handle navbar.inc? Should I just copy it, or copy-and-translate? Will ordinary translation-check header be enough to catch changes in English navbar.inc? Or Makefile should be somehow changed? Cheers! Lev Lamberov
Fwd: Tidy validation failed
Hi, starting on March 1st [1] debian-l10n-russian receives the following tidy validation error message. Seems that is because some problems with generating pl.ru.html (more specifically, a problem with data borrowed from somewhere). Could someone look at it? Thanks! [1] https://lists.debian.org/debian-l10n-russian/2016/03/msg2.html Перенаправленное сообщение Тема: Tidy validation failed Переотправка-Дата: Fri, 11 Mar 2016 16:18:20 + (UTC) Переотправка-От:debian-l10n-russ...@lists.debian.org Дата: Fri, 11 Mar 2016 16:01:57 + От: Debian Webmaster Кому: Yuri Kozlov *** /srv/www.debian.org/www/international/l10n/po/pl.ru.html line 787 column 317 - Warning: replacing invalid numeric character reference 130 -- You received this mail for the language code ru. Please edit webwml/english/devel/website/validation.data if this is not accurate. Please also update webwml/english/devel/website/ with the new coordinator(s) data. signature.asc Description: OpenPGP digital signature
Bug#821096: www.debian.org: filenames of generated by parse-advisory.pl files should include the revision number of DSA
Package: www.debian.org Severity: normal Dear Maintainer, Security Team issues revisions of DSAs, e. g. DSA-3485-1 and DSA-3485-2, but currently parse-advisory cannot handle revisions file-wise. That is, it creates dsa-3485.wml for the original DSA, but it is not so easy to create a revision when the latter is issued, because file dsa-3485.wml already exists. So, someone needs to, say, rename dsa-3485.wml, use parse-advisory to create a source page for the revision, then rename both wml files: the original DSA and its revision. To avoid that parse-advisory should add the revision number to filename of generated wml file. Sometimes (like in dsa-3485-1 and dsa-3485-2 case) it is not so easy to change the text of dsa-3485 in such a way that it would include both the original DSA and its revision, so it's better to store them in separate files. Cheers! Lev Lamberov -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#821096: Your mail
On Fri, 15 Apr 2016 22:44:02 +0900 victory wrote:
> # I do completely not understand what is not so easy :p
>
> the if clauses prevent re-generation of the files,
> so you can just remove the lines to always generate the file
> regardless of their existence
>
> first some lines of "make_data" subroutine
> if (-f $data){
> print "$data already exists!\n";
> return;
> }
>
> first some lines of "make_wml" subroutine
> if (-f $wml){
> print "$wml already exists!\n";
> return;
> }
>
> additionally, if you really need the dsa's revision in the file name,
> you can modify these lines to make what you want
> $wml = "$curyear/dsa-$dsa_number.wml";
> $data = "$curyear/dsa-$dsa_number.data";
>
> the line next to this will tell you what can be used
> $pagetitle = "DSA-$dsa_number-$dsa_revision $package";
>
>
> --
> victory
> no need to CC me :-)
>
>
Bug#821096: (no subject)
> the if clauses prevent re-generation of the files,
> so you can just remove the lines to always generate the file
> regardless of their existence
>
> first some lines of "make_data" subroutine
> if (-f $data){
> print "$data already exists!\n";
> return;
> }
>
> first some lines of "make_wml" subroutine
> if (-f $wml){
> print "$wml already exists!\n";
> return;
> }
I believe that it is not good, we should keep all revisions.
>
> additionally, if you really need the dsa's revision in the file name,
> you can modify these lines to make what you want
> $wml = "$curyear/dsa-$dsa_number.wml";
> $data = "$curyear/dsa-$dsa_number.data";
>
> the line next to this will tell you what can be used
> $pagetitle = "DSA-$dsa_number-$dsa_revision $package";
Yes, but that solves only a part of the problem. That is, we also need
to make changes to make_makefile subroutine. Then we need to fix
existing Makefiles (at least for 2016) and fix filenames of existing
DSAs (again, at least for 2016).
By the way, the same problem holds for parse-dla.pl and DLAs. Look, we
have (1)
https://lists.debian.org/debian-lts-announce/2016/02/msg00037.html and
(2) https://lists.debian.org/debian-lts-announce/2016/03/msg1.html,
but on the website we have only the latter:
https://www.debian.org/security/2016/dla-445.
Cheers!
Lev Lamberov
signature.asc
Description: OpenPGP digital signature
Bug#845297: Git hooks for translation versions
Hi, I was playing with git hooks and realized that they could be used in migration of the Debian website content from CVS to git and saving CVS-style translation versions (even throw away "1." part from 1.x and keep just x). I guess this will make the migration for translators easier and will not require to completely rewrite translation check scripts (although some changes will be needed). Let's store CVS-style version of every translatable file somewhere (in file, database, or another VCS, "db" hereafter). When someone pushes changes to the repository these changes are checked with git hook to fetch a list of changed files. I propose to use update hook, because (1) it get ref name to update, old and new object names as parameters, (2) git will accept push only in case when update hook returns 0. The (2) is important because we don't want to accept changes which are not reflected in db. I've wrote some skeletion script, please find it attached. All prints there are just for debugging purposes, and output is forwarded to git send-pack, so user will see it. Currently, it doesn't support merges, so only one parent commit for a given commit. Say the last commit on the server is eab5, and there are two file, aaa (version 1.2) and bbb (version 1.7). Someone makes three commits, f3ea (aaa changed), f2e6 (bbb changed), and d4e3 (both aaa and bbb changed), and pushes them to the server. The script fetches a list of new commits (f3ea, f2e6, d4e3) starting from the already known commit (eab5, not included) to the last new commit (d4e3, included), and iterates through the list. Since we have three commits there will be three iterations, each will produce a list of changed files. That is, we will get three lists: (aaa), (bbb), (aaa, bbb). What follows will depend on design details. I can see two possible ways: 1. Update db as follows: aaa=1.4, bbb=1.8 (one version bump per commit) 2. Update db as follows: aaa=1.3, bbb=1.8 (one cumulitive version bump per file for all commits) I'm not sure which way is better. We could also store not just the current version, but rather version history with commit ids corresponding to each version. I don't think I ever saw reverts in website content CVS, but guess it also should be taken into account (and it will require some additional work). I agree that it may require a lot of work, but still it is an additional alternative to consider. I'd say that gettext and po4a are good candidates, but there are some particular shortcomings already mentioned in the wiki. Cheers! Lev Lamberov update Description: update
Re: Debian website translations: old files removed, and later re-added, causing extra translator's work
Hi, First of all, I'd like to stress that while I am involved somehow into Russian l10n team the person who re-introduced Russian translations of releases/ham/* is not me. Чт 20 мар 2025 @ 11:27 Thomas Lange : > I removed the translation for most old releases, because I think it's > not worth to keep these translations. I like to keep only the english > version for old releases. I strongly believe that removing translations is a bad decision. It makes efforts of translation teams invisible. While translations are still in the repository one has to put efforts to find them. So, those removed translations are not visible for a wider audience. Also, it may cause bad feelings in those translators who still work in the respected teams. Guess, it may feel like your work has been thrown in the trash. While I agree that removing outdated translation which are far long not in sync with the originals could be justified, I don't see what justifies removing up-to-date translations of some old pages, even if those pages are kept only for historical means. > Here are some statistics about the russian translation and the english > pages: > > The numbers are GET requests from the last two weeks on all > our web servers, status only 200, excluding a long list of bot names. > > 49055 /releases/ > 775 /releases/index.en.html >1234 /releases/index.ru.html > > Nearly 50.000 hits for the english version of the main Debian releases > web page which lists a releases. 1234 for russian. Are you sure that 50k is the correct number for the english version? One may request www.debian.org/releases/, but then be redirected to some translation by means of content negotiation. I just don't know whether this ticks both /releases/ and /releases/index.SOMETHING.html. And if it ticks both then those numbers for english version are over-estimated. > Shouldn't the translators spend their time on content which is more > important? Is this a serious question or just rhetorical? > Maybe we need some advice to translator what is important and what not. > Or are rules (more strict) are needed? But what could justify such rules? Saving CPU time? Is it worth it? Best, Lev
