trans-coord-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Preparation for wider testing


From: Yavor Doganov
Subject: Preparation for wider testing
Date: Tue, 12 Feb 2008 23:35:42 +0200
User-agent: Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/22.1 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) (gNewSense GNU/Linux)

I am more or less pleased with how the thing behaves and the "API" is
stable (or at least it should be), so I would like that we concentrate
on fixing the remaining issues.  Here is how I imagine this:

  I. Phase One -- implement the missing important features.
 II. Phase Two -- RFC: Karl and the others.
III. Phase Three -- beta testing in this repository.
 IV. Phase Four -- enabling GNUN instance for www.

Ideally, between I-III it would be very nice to have another team to
do "alpha" testing, e.g. more or less what we do with the bg
translations now.

Of course, we will constantly improve the documentation, but some real
feedback from translator(s) would be more than welcome.

Here are the showstoppers (IMO, of course):

a) Error handling.  There are several types of errors, and I want all
of them to be mailed to the relevant parties (i.e. the presumably
"guilty" parties).  This is important, because we can't really be
babysitting the whole process in the long term.  It is important to
note that it is not enough to capture errors from xmllint in the
validate-html script -- sometimes m4 will spit an error, like a typo
in a directive that can't be expanded.

b) "Report" target.  It is essential to know the pending tasks.  A
team should figure out what articles need updating with only one
command and no extra effort.

c) Support for language team areas.  How will we (www-bg team) use
GNUN, for example?  It is entirely incompatible with our current
translation practice.  We need to solve this problem and recommend a
viable solution.  Teams will have the option not to follow the advice
and invent their own ways, of course.  But there should be a
straightforward way.

d) Figure out how to handle translations of /server/whatsnew.xx.html
and gnusflashes.xx.include.  It seems redundant to me to have XSLT for
all languages (and a rule in rss/Makefile), but I can't think of any
other solution.

There are many other things to do, but we shouldn't delay deployment
just because we think the system is not ideal.  (The full deployment
will take years, and I anticipate at least a year for the active
teams.)

I'll work (work == think, for the time being) on a) and b), in
parallel.  c), when invented, might give us a clue how to proceed with
pages under /software, but that's low priority.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]