YABug in gettext-0.14.2 -- fuzzy matches non-upgradeable.

[Steve Murphy]

Hello--

Another bug for gettext. I was merging in translations into files that
have fuzzy translations, and noticed that never, not once, are the fuzzy
matches reduced during a merge. Surely, I thought, at least one fuzzy
match should have been upgraded to an exact match.

So, I dug thru the code. And, sure enough, the non-null msgstr insures
that the fuzzy match in the "def" is the first found, and is treated
like an exact match:

from message_list_list_search, message.c:

      mp = message_list_search (mlp, msgid);
      if (mp)
        {
          int weight = (mp->msgstr_len == 1 && mp->msgstr[0] == '\0' ? 1 : 2);
          if (weight > best_weight)
            {
              best_mp = mp;
              best_weight = weight;
            }
        }

I changed this to read:

      mp = message_list_search (mlp, msgid);
      if (mp)
        {
          int weight = (mp->msgstr_len == 1 && mp->msgstr[0] == '\0' ? 1 : 2);
          if( mp->is_fuzzy ) /* an exact match will outweigh a fuzzy match */
                  weight = 1;
          if (weight > best_weight)
            {
              best_mp = mp;
              best_weight = weight;
            }
        }

A fuzzy message would normally get a weight of 2, because it has a non-
null msgstr. Since the def gets the 1st position in the list, it's msgid
will match the ref's msgid first, and the fuzzy match will be matched
first, and no other match (even exact), weighs more, so it is the match
returned. My change makes fuzzy matches as good as null matches.

This works, but.... introduces a new problem. Any exact matches found,
will end up setting that as the match, and the exact match will set the
correct msgstr in the outgoing PO file. BUT, the old fuzzy string is
output as "obsolete". Since an obsolete msgid seems to get parsed in the
file, having an obsolete msgid match one of the msgid's in the file
causes an error in msgfmt. I again dived into the code, and came up with
a solution, however, I suspect it isn't optimal. In the routine that
will print an obsolete entry to the PO file, I merely had it return if
the message is fuzzy. Think about it-- why would you ever want to save a
fuzzy message? If it's obsolete, just let it drop. It was most likely
wrong to begin with.

I made the change in write-po.c, in the routine message_print_obsolete:

...
  /* Separate messages with a blank line.  Uniforum doesn't like blank
     lines, so use an empty comment (unless there already is one).  */
  if (blank_line)
    print_blank_line (fp);

  /* Print translator comment if available.  */
  message_print_comment (mp, fp);
  
!  /* I'm sorry, but saving fuzzies as obsolete? Why would we
!        want to create uniqueness errors? They were fuzzy for a 
!        reason-- they were inexact. And they are now obsolete because
!        (I presume) either an exact or better fuzzy match was found.
!        So lose them.
!  */
!  if (mp->is_fuzzy)
!         return;
  
  /* Print flag information in special comment.  */
  if (mp->is_fuzzy)
    {
      bool first = true;

      putc ('#', fp);
      putc (',', fp);
...

I marked my changes in the above with !'s.

Am I way off target here? Anyway, the behavior is now something I'd
expect.

murf

signature.asc
Description: This is a digitally signed message part