[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: view-fuzzy beta version ready
From: |
Yavor Doganov |
Subject: |
Re: view-fuzzy beta version ready |
Date: |
Wed, 31 Mar 2010 16:55:23 +0300 |
В 01:04 +0200 на 25.03.2010 (чт), George Zarkadas написа:
> The script is in beta now, and have already passed all po files in
> philosophy (and gnu) subtrees with reasonable speed and no obvious at
> first sight errors.
Thanks!
But first of all, I apologize for the late response.
http://cvs.savannah.gnu.org/viewvc/www-el/__tools__/view-fuzzy?revision=1.12&root=www-el&view=markup
It is huge (nothing wrong with that, of course). I hope to be able to
(finally!) review and test it carefully within this week.
> All wdiff options that make sense
About wdiff and the bug you filed: you would need to rebase your patch
on wdiff trunk as it changed significantly since 0.5. There was a major
new (long awaited) release a few days ago. This command works for me:
$ bzr branch http://bzr.savannah.gnu.org/r/wdiff/trunk
(Savannah has a bug in presenting info about Bzr, which is probably why
you were unable to fetch the latest stuff.)
More importantly, why is --diff-mode needed at all? We definitely want
word-based diff and I fail to see where char-based one would be useful.
(This is consistent with the classic diff -u/-c where you get
line-by-line diff in both cases.) If `fredom' is a typo'ed `freedom'
which gets fixed, I want to see _fredom_*freedom* and not fre*e*dom, but
that's probably because my mind was taught this way through the years.
Could you elaborate on the necessity of `--diff-mode=c'? Eventually, it
could be helpful if there's a typo in an annoyingly long URL, but in
such cases I always copy the msgid directly to avoid editing the URL
itself.
> [with color ]: view-fuzzy -h c -a /some-path/www/gnu/po/*.xx.po
This should be the default action. i.e. `view-fuzzy article.LANG.po'
should behave this way by default, if no other options are given.
> In addition, when we are certain that no spurious errors may result in
> data loss of the original file's msgids and msgstrs, then I believe it
> will be relatively easy to incorporate in the team's GNUmakefile a
> repository update mode that will automatically merge the diffs in
> local team's po files. What's your opinion about this?
Note that not all people like the traditional wdiff markup. We can have
a rule in GNUmakefile.team, of course, but it should be optional (i.e.
no other rule must depend on it), and a team leader should invoke it
within the team's repository only when there's consensus among the team
members. Naturally, the rule would be a great convenience in such
situations.
Some very rough and generic comments (I haven't done a thorough review
yet):
* Since the name `view-fuzzy' is very generic, the script should
be called `gnun-view-fuzzy' or `gnun-compare-msgids'. This is
to avoid eventual file conflicts when installed in a common
location like /usr/bin and /usr/local/bin (gnun-validate-html
used to be named validate-html, but we changed it before the
first public release solely for this reason).
* If we're going to incorporate the script in GNUN proper (I
hope), then you'd have to assign copyright to the FSF. I'll
send you more details off-list.
* APPNAME, VERSION, etc. should be generated automatically and
match the version/description of GNUN itself. See how the other
scripts are built and don't worry about the autotools stuff, I
can easily do it myself when we install it in the trans-coord
repo.
* Please follow the GNU Coding Standards (they are mostly
C-centered, but you can "derive" the same for shell scripts --
see gnulib/build-aux if you feel lost and need to see real-life
examples).
* As this is going to become an important program (the most used
and important for translators, actually), it has to be properly
documented in doc/gnun.texi. Again, feel free to leave this
task to me, especially if you're not familiar/confident with
Texinfo. No worries here.