On Tue, May 17, 2005 at 01:38:54AM +0200, Frans Pop wrote: > (trimming CC list for this subject) > > We (/me and djpig) thought of that and that has already been taken care of > (no more Spanish translations in about 3 hours ;-) Actually, what did you change? http://www.debian.org/releases/testing/releasenotes.en.html does not shop up the Spanish translation even if it's in the list of %langsrelnotes in release.data. The files are being compiled and installed (i.e. http://www.debian.org/releases/sarge/$ARCH/release-notes.es.txt, is available) but the links are not getting created in the table. The only change I see to the release notes pages [1] changes permute_as_matrix to permute_as_matrix_new. Why doesn't Spanish show up there? I find it confusing that the release.data information is not honored properly by the wml file. The .data file should be used to determine which languages are shown there, but there are many langs there that are not listed in the resulting html file. Let me make a wild guess: since releasenotes.wml depends on release.data and on the release info it will only get regenerated when those two are changed. However, the new code used for releasenotes.wml tries to second guess the release.data information and will _not_ produce hyperlinks to documentation if there are no HTML/PDF/TXT files in the expected directories. Thus, simply removing the files generation from the DDP CVS Makefile and cleaning up old files will make those languages disappear from the index (that's what you accomplished) However, even if new languages are updated (and are added to the Makefile in the CVS DDP so that they are installed in the next run) the wml file will _not_ get regenerated (the release.data file has not changed) and the new language will _not_ show up in the index (even if its files are there). This (new?) behaviour is really confusing and counterintuitive, it probably also forces us to manually modify the Makefile dependancies or force a manual update on the wml file. Or, even, to have the releasenotes.wml file be regenerated in each webwml run (fake dependancy?) just to make sure that it is current. I think it would be best if the wml code in the release template did not tried to second-guess the information on releases.data and would just produce the links "as is" for the wml pages. The procedure to add a new language previously was: [ done by the doc team or translators ] 1- Add the translation to the CVS DDP 2- Modify the CVS DDP Makefile so the language gets added [ done by the web team when the docs are considered OK ] 3- Modify the release.data file in the WWW CVS so that the language gets added to the index Removing a language was as easy as just editing release.data. It would still get published (unless the CVS DDP Makefile is modified) but will not be linked from the official page. This is not necessarily bad, yes, some (external) links might point to these and they are shown through content negotiation, but this allows translators to have "preleases" that they can ask people to review (by pointing to the hidden files) and separates properly DDP work from the WWW work. I find the above procedure much better than having to: 1- Add the translation to the CVS DDP 2- Modify the CVS DDP Makefile so the language gets added 3- Modify the release.data file in the WWW CVS so that the language gets added to the index 4- Ask a debian-www administrator to force a run so that releasenote.html gets regenerated. Notice that if the WML generation is done before the DDP run finishes (which would provide the expected files due to 2) then, even if all the files are telling you that the language will be added to the index it actually isn't (since the WML code did not find the files through it's run). So it's back to 4 again, pestering debian-www administrators with the task of manual regeneration. I'd rather have the procedure above, even if it might generate broken links from time to time (if a translation is removed from the CVS DDP Makefile but not from the release.data file), as manual regeneration is not needed at all and the DDP and WWW compilation runs can be done independently one from each other. If we want users to be forewarned that translations are not up to date then this should be implemented in the DDP CVS front just as is done in the WWW CVS. I.e.: have all translations depend on the original language files, if these files changed, remake the translations and add a header saying "This is an out of date translation. If in doubt, review the original document available <here>" Regards Javier [1] http://cvs.debian.org/webwml/english/releases/sarge/releasenotes.wml.diff?r1=1.2&r2=1.3&cvsroot=webwml
Attachment:
signature.asc
Description: Digital signature