Hi Derek, Am Dienstag, den 22.04.2008, 10:23 -0400 schrieb Derek Atkins: > Christian Stimming <[EMAIL PROTECTED]> writes: > > > Quoting Derek Atkins <[EMAIL PROTECTED]>: > >>>> 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 empty msgstr http://www.gnu.org/software/gettext/manual/html_node/Untranslated-Entries.html#Untranslated-Entries 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. http://www.gnu.org/software/gettext/manual/html_node/Fuzzy-Entries.html 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 :-) -- andi5
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
