bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: Method behind the madness?


From: Bruno Haible
Subject: Re: Method behind the madness?
Date: Mon, 14 Mar 2005 13:32:28 +0100
User-agent: KMail/1.5

Hello,

Steve Murphy wrote:
> I note that the provided fuzzy matching, at least for the
> language I'm working with (Kinyarwanda), is very disappointing.
...
> 2. If the def po file has a matching msgid, and the msgstr is empty,
>     then, unless an exact match with something better
>     in it is found later in the definitions lists, then, the empty
>     msgstr ("") is used, and no fuzzy matches are attempted.
>     This puzzled me. Indeed, it seems that the only time a fuzzy match
>     will be attempted, is if there is an entry in the
>     POT (ref), which is new, and no matching msgid exists in the "def"
>     po. After the PO file has the msgid, there is
>     no longer any opportunity to fuzzy match it.
> 
> Is #2 a bug, or a feature?

It was designed like this, but this was before translators started using
compendia.

Just to make sure that I understood your suggestion correctly:
  - You are using compendia?
  - The fuzzy matching is disappointing for you because the PO file that
    you receive has already been msgmerged without your compendium, and
    then when you msgmerge with your compendium, your compendium is
    entirely ignored?

> By changing the code in msgmerge.c (line
> 935, in func match_domain) from:
> 
>       defmsg = message_list_list_search (definitions, refmsg->msgid);
>       if (defmsg)
>       {
>         /* Merge the reference with the definition: take the #. and
> 
> to:
> 
>       defmsg = message_list_list_search (definitions, refmsg->msgid);
>       if (defmsg && defmsg->msgstr && defmsg->msgstr[0] )
>       {
>         /* Merge the reference with the definition: take the #. and
> 
> 
> gives behavior I would expect.  --- Perhaps I should say, behavior ****
> I **** would expect.
> 
> Now, I'm kinda young to this code, and I am unschooled in all the subtle
> craftiness and complexity

Even if your modification is not perfect, it is a good help in understanding
the problem you are facing.

> One other thing, that I think could be considered a bug. I've read the
> info manual, and the man pages
> for msgmerge, and all the other verbage in the info doc, but nowhere did
> I find any kind of description
> of just how the fuzzy matcher works.

He he, there must be undocumented things somewhere :-) 

> And I see the code in the src directory for the fuzzy matching, but
> there is really no explanation of the algorithm, and it is not
> intuitively obvious (at least, not to me), exactly
> what the algorithm is doing. I can kinda see how it (fstrcmp) assigns a
> "value" to the "closeness" between strings,
> and selects the "closest" string from the lot.

Yes. That's all there is to it. And the "closeness" is defined in fstrcmp.c
as   ((number of chars in common) / (average length of the strings)).

Bruno





reply via email to

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