[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. 


But first of all, I apologize for the late response.

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

(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

> [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, 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

Some very rough and generic comments (I haven't done a thorough review

      * 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
      * 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
      * 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.

reply via email to

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