Re: [i18n]Source packages and translation templates q.
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?"
Reply to: