Re: Make GNUN more user-friendly

[Ineiev]

On 08/29/2013 12:06 PM, Thérèse Godefroy wrote:
>
> Update doesn't seem to work if the CVS entries don't mention the new
> file. But maybe I did something wrong.

Hm..

address@hidden:~/co$ cvs -d:pserver:address@hidden:/web/trans-coord co 
trans-coord/trans-coord.html
U trans-coord/trans-coord.html
address@hidden:~/co$ cd trans-coord/
address@hidden:~/co/trans-coord$ ls -a
.  ..  CVS  trans-coord.html
address@hidden:~/co/trans-coord$ cat CVS/Entries
/trans-coord.html/1.3/Fri Mar  8 11:25:38 2013//
D
address@hidden:~/co/trans-coord$ cvs up .symlinks
U .symlinks
address@hidden:~/co/trans-coord$ ls -a
.  ..  CVS  .symlinks  trans-coord.html
address@hidden:~/co/trans-coord$ cat CVS/Entries
/trans-coord.html/1.3/Fri Mar  8 11:25:38 2013//
/.symlinks/1.1/Fri Feb 13 11:56:41 2009//
D

>> I assumed the context of broken headers; I meant that the user
>> should commit a fix rather than exclude them from validation.
>
> Fine, but it depends on the user. A translator is primarily concerned
> with her translation, not with the site itself.

I'm used to think that translations exist for the site; there may be
people who work on translations primarily for different reasons, but
it is disputable whether we should support such users (rather than
make it easier to do a complete validation for all people who need
validation, for instance).

> She usually doesn't
> have much time to spare, and can't afford to be distracted by side
> issues, but still would like to have a decent page to proofread.

I can't imagine a piece of proofreader's job (especially when she
proofreads the translations by batches) that wouldn't be essentially
larger than committing a validation fix, so it doesn't get much time.

> People who are interested in fixing the site can use the complete
> setup.

This works in a different way: GNUN's cron job sends a message
to the relevant list.  in theory, the same could be done with
the translations staged in team's repository.

>>  > While we are at it, why not make a nice-looking deb out of all that, and
>>  > use Debconf?
>>
>> To tell the truth, I don't clearly understand what "all" is, what
>> Debconf is, and...
>
> "All" is "all there is in trans-coord/gnun/server/gnun". You would get a
> set of packages (binary, source, etc.). The "binaries" could be
> installed as usual, with dependencies taken care of, without any need
> for autoconf et al.

Autotools are needed to prepare a GNU Coding Standards-compliant
distribution tarball (strictly speaking, they are not needed,
but in practice it's the tool to make the job feasible).

> Debconf is something you wouldn't like because it is made to be
> interactive.  ;)
> It stores configuration parameters after (or before) installation of the
> package, using defaults or data provided by the user. The debconf
> database can then be used by the post-installation script and some other
> programs.

I still strongly suspect I don't understand it very well...
do you mean maintaining a Debian-type package?

If yes, then it is a different activity (from maintaining
the "upstream"), and it is typically done by other people.

I can't tell whether it has ever been done by anybody, I think it
hasn't, because GNUN user base is very small, and such a package would
only cover a part of it (it might even not cover all major Debian
derivatives), so there would be little useful result.

> For instance, if the list contains both updates and proofreadings, I
> will remove the proofreading from the first pass of transvalidate, and
> commit with "1" (Update), then do a second pass and commit with
> "2" (Proofreading). If some POs only had a few modifications, there
> would be a third pass with "3" (Minor fix). Pure laziness.

I see; I wouldn't call it pure, though: if it were pure, it would
avoid running the editor twice.