It seems, the dialog appears, if you post an invoice (a bill, a voucher?) and probably other places(?) where it uses the following different labels:

"Do you really want to post the invoice" 
"Post Date"
"Due Date"
"Description"
"Post to account"
"Accumulate splits?"

So it seems, all labels are replaced later by something more meaningful. 

I will remove the translatable flags and this strings will no longer remain in new POT files.

Geert, do you remember from your conversion more glade files, which have gotten translatable flags by accident?

John, how should we provide an updated gnucash.pot to Joe and perhaps other TP users?

If a translator wants an updated pot we can email one or if s/he has the requisite skill s/he can build it. The Translation Project's policy is that they work only on potfiles from the latest release tarball, so they'll have to wait until the next release.

But as David T. pointed out on the user list we should probably do a snap release soon to get the QIF import fix out there, so it needn't be too long a wait.

Created attachment 318273 [details]
gnucash.pot

In commit bd3406e the translatable flag from placeholder labels in dialog date-close is removed.

You can use the attached recent gnucash.pot to update your po file as shown in http://wiki.gnucash.org/wiki/Translation#Updating_an_existing_.po_file .

Thanks for reporting!

This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.

(In reply to Frank H. Ellenberger from comment #1)
> Geert, do you remember from your conversion more glade files, which have
> gotten translatable flags by accident?
> 
The "by accident" already suggests I was not aware several dummy strings became marked as translated. It's also been quite a while since I did the conversions. So no, I don't know which other glade files may be affected. Sorry.

(In reply to Frank H. Ellenberger from comment #1)
> John, how should we provide an updated gnucash.pot to Joe and perhaps other
> TP users?

How about checking the updated gnucash.pot in in our repository and point the interested translators to the downloadable version on github ?

That seems a bit more resilient to bit rot than an static version added to this bug.

(In reply to Geert Janssens from comment #6)
> (In reply to Frank H. Ellenberger from comment #1)
> > John, how should we provide an updated gnucash.pot to Joe and perhaps other
> > TP users?
> 
> How about checking the updated gnucash.pot in in our repository and point
> the interested translators to the downloadable version on github ?
> 
> That seems a bit more resilient to bit rot than an static version added to
> this bug.

gnucash.pot is a built file and so shouldn't be in the repository.

(In reply to John Ralls from comment #7)
> (In reply to Geert Janssens from comment #6)
> > (In reply to Frank H. Ellenberger from comment #1)
> > > John, how should we provide an updated gnucash.pot to Joe and perhaps other
> > > TP users?
> > 
> > How about checking the updated gnucash.pot in in our repository and point
> > the interested translators to the downloadable version on github ?
> > 
> > That seems a bit more resilient to bit rot than an static version added to
> > this bug.
> 
> gnucash.pot is a built file and so shouldn't be in the repository.

Right. That makes sense. I seem to remember it used to be checked in, but it clearly isn't any more.

Some time ago I used to msgmerge a recent pot in our po files after mayor string changes. 
But this can result in conflicts for TP maintained files and IIRC I read somewhere, devs shouldn't do it.

So how should be our policy?

We should msgmerge our po files periodically. Benno, the TP coordinator, does that with every tarball (which has a potfile, perhaps why they insist on release tarballs), merging the new potfile with the existing po files, then updates the stats on the status page with the results. I merge those po files into our repo immediately before every release. Since that's a downloaded file merge rather than a git repo merge it doesn't produce any conflicts, but any changes to a TP-managed po file that isn't from TP will be lost. 

If we *don't* msgmerge the po files in our repo then the non-TP ones will never get updated and translators will be working on the wrong msgids. I do it when I think of it but it should be in the release process so that it's done at least every release.

Thanks for taking care of this. A new file on TP later on is fine.
bye
Joe

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=760079. Please update any external references or bookmarks.