I use the same versions of gettext and intltool in Debian Stretch

Mentioned change in github was made due to the fact that translations should differ depending on the context for russian language (i guess ukranian and belarus users could also be affected). 
Before this PR there was a discussion in dev mailing list and developers agreed to support context parameter, to provide users better sounding translations.

Is this is a so huge problem to update gettext to a newer versions with support of this capability?

There is no newer version of gettext and fell and I use the same version of gettext.

Well this is interesting: On the same Debian stable VM, the one that I used last weekend to build the release, I have builds from both master and that release. gnucash.pot in the master build has the msgids in question while the one in the release doesn't. I don't understand why, there are no differences between the two branches in Makefile.am or po/Makefile.in.in and gnc-frequency.glade is in POTFILES.in in both branches.

Meanwhile on OS X with gettext-0.19.4 and intltool 0.51.0 these msgids are in the maint gnucash.pot. 

The gettext and intltool versions on Debian Stable are 0.19.3 and 0.50.2 respectively.

http://lists.gnucash.org/logs/2015/12/2015-12-26.html#T15:54:33:
<jralls> fell: On the gnc-frequency.glade msgid contexts, I found that rather bizarrely it depends on whether I build in-source or out-of-source. In-source builds don't pick up the msgids and out-of-source builds do. This on Debian Jessie.

So we have a dilemma:

builddir:
 has absolute pathes for most files
 but recognizes msgctxt correctly
 make check fails

intree;
 entries with msgctxt are silently ignored

further notes:
build/po/makefile.in:
srcdir = /home/frank/workspace/Gnucash-Maint/po
top_srcdir = /home/frank/workspace/Gnucash-Maint
top_builddir = ..
VPATH = /home/frank/workspace/Gnucash-Maint/po
:
po/makefile.in:srcdir = .
top_srcdir = ..
top_builddir = ..
:

build/make-gnucash-potfiles has absolute pathes for @skipped_files@, ignored_files, @possible_files

make check failure:
Making check in po
make[1]: Entering directory `/home/frank/workspace/Gnucash-Maint/build/po'
INTLTOOL_EXTRACT="/usr/bin/intltool-extract" XGETTEXT="/usr/bin/xgettext" srcdir=/home/frank/workspace/Gnucash-Maint/po /usr/bin/intltool-update --gettext-package gnucash --pot
rm -f missing notexist
srcdir=/home/frank/workspace/Gnucash-Maint/po /usr/bin/intltool-update -m
The usage of POTFILES.ignore is deprecated. Please consider moving the
content of this file to POTFILES.skip.
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.

many .scm files below build/src/

I don't see anything wrong with that make check failure.

I do agree that the paths in gnucash.pot get strange when building out-of-source. I prefer to do so in-source for dists so that translators who work mostly from tarballs get paths that aren't full of a lot of garbage.

The context-tag behavior is very strange. It's xgettext that does that, right?

Looks like gtksourceview decided to drop Intltool altogether because of gtkbuilder problems: https://mail.gnome.org/archives/commits-list/2015-October/msg00448.html

For today's release I'm packaging from a build directory to get the four msgids included in gnucash.pot, but I'm not happy about it because of the ugly paths:
../../po/../src/foo.

As far as I understand it now, intltool is a wrapper for glib-gettext.
And GLib deprecates it's gettext macros (Bug 624186 - Deprecate glib-gettext macros) and suggests the gnu gettext package ...

So I know, where to go.

Note:
In a separate builddir, you can avoid the absolute path by running
 ../configure --srcdir=..
This will result in pathes of the form
../../po/../src/...
in gnucash.pot.

Perhaps this can be tweaked further by a modified form of calls.

(In reply to Frank H. Ellenberger from comment #9)

> Note:
> In a separate builddir, you can avoid the absolute path by running
>  ../configure --srcdir=..
> This will result in pathes of the form
> ../../po/../src/...
> in gnucash.pot.
> 
> Perhaps this can be tweaked further by a modified form of calls.

Does this work if you try:
  ./configure --srcdir=.

?

Uh, no, intltool is a set of perl programs that help with generating the localization boilerplate and generating the catalog file. It has nothing at all to do with anything Gnome with the sole exception of checking for the glib gettext wrappers when deciding whether a file should be in POTFILES.in.

Makefile.in.in, which is supplied by intltoolize, already does the relative path thing, but what we really want is for it to write paths relative to $(srcdir).

Telling it that srcdir=. from a separate builddir will fail to find any files to scan.

(In reply to John Ralls from comment #8)
> For today's release I'm packaging from a build directory to get the four
> msgids included in gnucash.pot, but I'm not happy about it because of the
> ugly paths:
> ../../po/../src/foo.

FWIW, I can't reproduce this any more on my Fedora 23 box. Currently it has
gettext-0.19.7-3.fc23.x86_64
intltool-0.51.0-3.fc23.noarch

I'm (as always) building out of tree in a build directory and get full pathnames in POTFILES:
../../../../gnucash/src/foo
but pathnames relative to the source directory in gnucash.pot:
#: ../src/foo

Either it got fixed in the more recent gettext version or Fedora added its own patch for it.

The other part of this bug is still reproducible though: translatable strings with context found in glade files are still missing from gnucash.pot when building in-tree.

John, Frank, it's been over a year I ran my last test. I've upgraded to Fedora 25 by now which ships gettext 0.19.8. gnucash.pot is still correctly using paths relative to ${srcdir}/po. And intree builds are still missing the msgids with context.

How is your build environment currently ? Does it come with a more recent gettext and does it work correctly with out of tree builds ?

If so I would propose to recommend gettext 0.19.7 together with out of tree builds and lower the severity of this bug.

I see debian jessy ships 0.19.3 by default but has 0.19.8 in backports.

This bug can then be left open to search for a solution for in tree builds and optionally dropping intltool.

I'm using 0.19.8 on MacOS, but MinGW provides only 0.18.3 (we're using 0.18.1) and ftp.gnome.org's win32 binaries has only 0.18.1. I've been trying to build 0.19.8 on Windows but some recent changes to the MingGW headers (to try and balance Microsofty and POSIXy naming) is making it hard.

On my old opensuse I have gettext 0.19.8.1, but still get absolute pathes. So probably this part is some issue of Eclipse and not gettext.

But I have no problem to replace the path between 'make pot' and msgmerge.

I find it more annoying, that intltools (last release 2015) makefile is missing most recent parameters of gettext.

I forgot, I found warnings like this in my configure.log:
conftest.c:60:6: warning: conflicting types for built-in function 'dcgettext' [enabled by default]
 char dcgettext ();
      ^

I don't know if they are important.

(In reply to Frank H. Ellenberger from comment #17)
> I forgot, I found warnings like this in my configure.log:
> conftest.c:60:6: warning: conflicting types for built-in function
> 'dcgettext' [enabled by default]
>  char dcgettext ();
>       ^
> 
> I don't know if they are important.

I've not noticed warnings like that, so I suspect it's your build environment. Since you're not passing those binaries around it probably doesn't matter much as long as everything works well enough... but if you start to see translation bugs then you should clean that up first before digging in to the code.

About my guess in comment #16:

After git clean ...
and running autogen, configure, make in the shell instead of eclipse I get a srcdir="../../po" in make pot 
resulting in pathes of the form "../../po/../src..."

So the absolute path is a bad substitution of eclipse - or we did not set it the right way.

make check fails because it believes to see additional translatable files where we   symlinks have from build/<somePath> to ../<somePath>
If 'find' is used here, then it is missing the option '-name-type l' to ignore links.

Frank, I'm not sure I understand exactly what you are saying.

In comment 16 you say you still get absolute paths. In which files ?
- <srcdir>/po/POTFILES.in,
- <srcdir>/po/*.po
- <builddir>/po/POTFILES
- <builddir>/po/gnucash.pot

And I don't quite follow what you mean by 
> But I have no problem to replace the path between 'make pot' and msgmerge.

Do you mean you replace those manually then ?


> make check fails because it believes to see additional translatable files
> where we   symlinks have from build/<somePath> to ../<somePath>
> If 'find' is used here, then it is missing the option '-name-type l' to
> ignore links.

I don't see this. Can you post the error message ?

(In reply to Geert Janssens from comment #20)
> Frank, I'm not sure I understand exactly what you are saying.
> 
> In comment 16 you say you still get absolute paths. In which files ?
 - <srcdir>/po/POTFILES.in,   correct: src/...
 - <srcdir>/po/*.po           untouched before msgmerge
 - <builddir>/po/POTFILES     correct: ../../src/
 - <builddir>/po/gnucash.pot  overhead: ../../po/../src/
 
> And I don't quite follow what you mean by 
> > But I have no problem to replace the path between 'make pot' and msgmerge.
> 
> Do you mean you replace those manually then ?
yes 
 
> > make check fails because it believes to see additional translatable files
> > where we   symlinks have from build/<somePath> to ../<somePath>
> > If 'find' is used here, then it is missing the option '-name-type l' to
> > ignore links.
> 
> I don't see this. Can you post the error message ?

# cd ../build/po
# make check
file=`echo de | sed 's,.*/,,'`.gmo \
  && rm -f $file && /usr/bin/msgfmt -o $file de.po
rm -f missing notexist
srcdir=../../po /usr/bin/intltool-update -m
The usage of POTFILES.ignore is deprecated. Please consider moving the
content of this file to POTFILES.skip.
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.

build/src/app-utils/app-utils.scm
 : (all in build linked .scm files)
build/src/tax/us/txf.scm

If some of these files are left out on purpose then please add them to
POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
of left out files has been written in the current directory.
Please report to https://bugzilla.gnome.org/page.cgi?id=browse.html&product=GnuCash
if [ -r missing -o -r notexist ]; then \
  exit 1; \
fi
Makefile:801: recipe for target 'check' failed
make: *** [check] Error 1

(In reply to Frank H. Ellenberger from comment #21)
> (In reply to Geert Janssens from comment #20)
> > Frank, I'm not sure I understand exactly what you are saying.
> > 
> > In comment 16 you say you still get absolute paths. In which files ?
>  - <srcdir>/po/POTFILES.in,   correct: src/...
>  - <srcdir>/po/*.po           untouched before msgmerge
>  - <builddir>/po/POTFILES     correct: ../../src/

Ok those are like on my system.

>  - <builddir>/po/gnucash.pot  overhead: ../../po/../src/

Looks like this is an intltool bug that got fixed in 0.51:
http://bazaar.launchpad.net/~intltool/intltool/trunk/revision/746
So we should require 0.51 for release builds.

> > > make check fails because it believes to see additional translatable files
> > > where we   symlinks have from build/<somePath> to ../<somePath>
> > > If 'find' is used here, then it is missing the option '-name-type l' to
> > > ignore links.
> > 
> > I don't see this. Can you post the error message ?
> 
> # cd ../build/po
> # make check
> file=`echo de | sed 's,.*/,,'`.gmo \
>   && rm -f $file && /usr/bin/msgfmt -o $file de.po
> rm -f missing notexist
> srcdir=../../po /usr/bin/intltool-update -m
> The usage of POTFILES.ignore is deprecated. Please consider moving the
> content of this file to POTFILES.skip.
> The following files contain translations and are currently not in use. Please
> consider adding these to the POTFILES.in file, located in the po/ directory.
> 
> build/src/app-utils/app-utils.scm
>  : (all in build linked .scm files)
> build/src/tax/us/txf.scm
> 
> If some of these files are left out on purpose then please add them to
> POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
> of left out files has been written in the current directory.
> Please report to
> https://bugzilla.gnome.org/page.cgi?id=browse.html&product=GnuCash
> if [ -r missing -o -r notexist ]; then \
>   exit 1; \
> fi
> Makefile:801: recipe for target 'check' failed
> make: *** [check] Error 1

I have experimented a bit. I can only replicate this error is there is an old build directory in your source directory (different from the build directory you're using to run make check).


So make check finds duplicate links if the source tree looks like this:
<base>/<srcdir>/configure
<base>/<srcdir>/build       <- build dir not in use but still there
<base>/build                <- build dir used to run make check

Can you verify this ?

As a general remark searching around for this many sources are indeed suggesting intltool is dead and it would be good to replace it with gettext directly as it now understands most of the relevant source file types.

The original issue this report describes of translatable strings gone missing if they have a "context=" tag in glade files essentially appears to be an intltool bug. Intltool has recently been removed from our tool chain and with pure gettext I can't replicate this any more.

In-tree or out-of-tree builds both properly include the translatable strings.

Time to close this bug.

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