Res: File trashed by previous translator ?
andi5.py at gmx.net
Tue Apr 22 18:22:56 EDT 2008
Am Dienstag, den 22.04.2008, 10:23 -0400 schrieb Derek Atkins:
> Christian Stimming <stimming at tuhh.de> writes:
> > Quoting Derek Atkins <warlord at MIT.EDU>:
> >>>> 1313 #: ../src/business/business-gnome/glade/billterms.glade.h:10
> >>>> 1314 #, fuzzy
> >>>> 1315 msgid ""
> >>>> 1316 "Days\n"
> >>>> 1317 "Proximo"
> >>>> 1318 msgstr "Próximo"
> >>>> 1319
> >> This is a broken translation. The translation (msgstr) should include
> >> both the translation of "Days" and the translation of "Proximo"
> > Actually no, the translation is not broken, it simply hasn't
> > translated this msgid so far. Please note the marker "fuzzy" in front
> > of the translation - any translation marked as "fuzzy" is ignored by
> > the rest of the gettext system, just as if it had no msgstr
> > translation at all.
> That's not how I read it. If it hasn't be translated wouldn't the
> msgstr match the msgid?
no, I doubt that :-) Here my point of view:
When new strings are marked for translation, they are added with an
When strings change a little bit, msgmerge tries to find similar english
strings with translation and packs the new string and the translation
together, marking them as fuzzy. The translator can toggle the fuzzy
flag on every string, but I do not think this was the case here.
Anyway, fuzzy translations will no appear in the .mo file.
And the translation above would not be right, that is true as well.
In case I did not miss the truth completely again, I guess we can stop
discussing this issue now :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080423/44a7ff2a/attachment.bin
More information about the gnucash-devel