Translation template was not imported to Feisty

Ping.
Any comments, news, progress on this?

Beagle does't use Rosetta (at least not for our own translation work) however, I'll look into this on the Ubuntu side.

Ok, well we've now made it official that I know nothing about the Ubuntu Translation system, but if helps at all, I've attached the latest hu.po file....

If its outdated, the latests sources (for gutsy at least) live in a bzr branch

http://codebrowse.launchpad.net/~kkubasik/beagle/gutsy/files

Dunno if that helps at all. Please let me know so we can clean up some of these bugs.

Thanks, but this is not really a help, at least for all other languages around :)
Seems we need some assistance from rosetta developers, I'll ping them on mailing list.

Beagle translations are done through the GNOME Translation Project.

http://l10n.gnome.org/module/beagle

Daniel: I know, I have translated it :).
The problem is that the template and po files are not imported into Rosetta, so Ubuntu language packs do not contain any new Beagle strings introduced since Edgy, thus the application is not 100% translated, even it is fully translated upstream.

The problem with Beagle is that it's not regenerating its .pot file like most packages in Ubuntu do.

Once we adjust its build scripts to do it (Martin Pitt and Seb could help with this in an easy way), next beagle build will provide Launchpad with an updated .pot file and thus, this problem will be fixed.

Is there any documentation about how "most packages in Ubuntu" build, and how the build scripts generate .pot files? Just in case e.g. someone comes along with a new (translatable) package and wants to have translations in Launchpad as well, and avoid this bug, would they be able to find information on how to do it?

After talking with Seb and Martin, they told me that depend on the kind of package.

Here you have the log:

>carlos< but they are asking for a documentation in a public place to know what to do to get this fixed
>carlos< so new packages could get that done easily using the standard infrastructure
<seb128> carlos: run intltool-update -p, you should know that ;)
<pitti> carlos: unfortunately there is no general recipe, just some standard approaches
>carlos< seb128: don't we have a set of debuild rules to do that automatically?
<pitti> preferably those packages should use cdbs' langpack.mk
>carlos< if it's just a matter of call that command directly... yeah, I could answer :-P
<seb128> carlos: cdbs has, but if that doesn't work they don't use cdbs most likely
>carlos< that's it!
 oh
 so they don't need to call langpack.mk directly?
<pitti> carlos: langpack.mk depends on the other cdbs infrastructure
<seb128> gnome.mk uses it
>carlos< I see
<seb128> but beagle uses dehbelper
>carlos< ok
 thanks, I will note that on the bug report
<pitti> carlos: without cdbs: if the package uses intltool, use intltool-update -p; if not, it needs to be hacked manually
<seb128> so a cd po: intltool-update -p needs to be added to debian/rules
>carlos< seb128, pitti: ok, thanks
<pitti> --verbose, preferably, for buildd log debugging

I don't know the best place for this so please, feel free to add it to any web page you think should have it.

Btw, for KDE packages, the procedure is different, but I don't know it at all (they use their own gettext version...)

As beagle was thrown out of main, this is now irrelevant.