[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [i18n]Source packages and translation templates q.

I demand that Neil Williams may or may not have written...

> 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).

> 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...

> 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.

| 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: