Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2001:
[Freeciv-Dev] Re: headers in po-files
Home

[Freeciv-Dev] Re: headers in po-files

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: headers in po-files
From: Lino Mastrodomenico <mastro@xxxxxxxxxx>
Date: Tue, 26 Jun 2001 11:16:27 +0200

Gaute B Strokkenes wrote:
> On Mon, 25 Jun 2001, haible@xxxxxxx wrote:
> > Erik Sigra wrote on 2001-03-01:
> >> If I have the header fuzzy marked, the city report looks like in
> >> the screenshot cityreport.png. But when I remove the fuzzy line, it
> >> looks like in the screenshot cityreportwrong.png, which is clearly
> >> wrong. I didn't change anything else in sv.po between the
> >> screenshots. This doesn't necessarly mean that headers should be
> >> fuzzy marked. Maybe there is some other problem which is prevented
> >> from being triggered by fuzzy marking the header?
> >
> > It looks like you are passing the empty string to gettext(). When
> > you do that, GNU gettext() returns the header entry. This is a
> > feature.  If you want to use the empty string instead, you have to
> > do it explicitly:
> >
> >     const char *str = ,,,;
> >     if (str[0] != '\0')
> >       str = gettext(str);
>
> That was my first thought as well, but it's not the case.  For
> instance, if Freeciv was somehow passing an empty string then there
> shouldn't be any output when Freeciv is configured with --disable-nls,
> however this is not the case.  Also have a look at the two pictures
> that Erik attached to his message: the only difference between the
> Freecivs that produced them is that in the one with the correct
> translations the po header was fuzzy, in the one with the wrong
> translation it was not.  It is very difficult to see how this could
> possibly have an effect on the string that Freeciv passes to gettext.

The patch #1 is for the bug reported by Erik.
This is only for the gtk and xaw clients: the mui client seems to be already    
ok (although i cannot test it).

The patch #2 fixes a similar bug.

Now we can safely remove the fuzzys, i think.

ciao

-- 
Lino Mastrodomenico
E-mail: mastro@xxxxxxxxxx

Attachment: nofuzzy_bug1.diff
Description: Text Data

Attachment: nofuzzy_bug2.diff
Description: Text Data


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