Benno Schulenberg <[email protected]> writes: > But, but... /no/ project should keep its POT file under version control, > as it is a derived file. However, I see that for example util-linux and > nano do keep their POT file in VCS. Strange. Maybe because the older > gettexts kind of obliged them to do that?
Might be. Perhaps developer keeps a POT and PO files in a repository, when he doesn't want to require gettext-tools when building from checkout. >> > But... shouldn't then all "CATALOGS" be replaced with "POFILES" in that >> > stamp-po comment? Otherwise it doesn't make sense to me. >> >> I think you are right, the occurrences of $(CATALOGS) should be >> $(GMOFILES). > > Ehm... not $(GMOFILES) but $(POFILES), right? :) Sorry, I don't get what you mean. The stamp-po rule really updates $(GMOFILES), subsequently after $(POFILES) and $(DOMAIN).pot, no? > What I don't get is: why are there two recipes for msgmerging PO files? > Tthe "$(POFILES): $(POFILESDEPS)" one, and the ".nop.po-update:" one. > The first gets run when I touch the POT file, the second when I run > 'make update-po'. The first recipe uses --update, the second uses an > intermediate file. Why can't the two be melted into a single recipe? I do not know of the reason, but if the consolidation is possible in a portable way, that would be great. Regards, -- Daiki Ueno
