I demand that Neil Williams may or may not have written... [snip] > It comes down to a problem with the gettext design - it's too tightly > integrated into the upstream build process
Not to mention the source itself, given that the .pot is (normally) generated by invoking a specific target in po/Makefile. > to be able to easily handle separating the po/ directory into a separate > upstream tarball which could be updated separately from the rest of the > source code. Anybody who asks me to do that will get a negative answer, though I suppose that an interim release containing just updated .po files is possible (but that would rely on no strings having been changed). [snip] > Churn is the problem here, IMHO. Many packages just change too fast at > specific times to allow generated files like the POT into the VCS. i.e. > the source code is changing and whether or not the translatable strings > actually change, committing the POT every time (because it timestamps > itself every time it is checked) is a PITA. Agreed. There have been times when I've taken a diff and stripped out any hunks which change only line numbers... [snip] > Keeping an up to date POT file in VCS is generally the wrong approach > because it is a generated file and because intltool insists on timestamping > the damn file every time the build so much as looks at it. Agreed. Look in the xine-lib repository (upstream), for example, and you'll see some "translation synchronisation" commits. If the build process causes po/*.po{,t} to be regenerated, those changes are (normally) manually discarded before the next commit. [snip] -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Toon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | back! | + They're after you... "You mean I can send mail to myself?" -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515806bf68%li...@youmustbejoking.demon.co.uk