In the process of searching for uses of ErrorDialog which
did not have a "parent" argument, I stumbled on this module
-- and noticed something different in it.
Benny changed the original "ErrorDialog" calls to a
"ERROR = ErrorDialog" variant in
9a2fd50642
on 30 January 2011, "to allow a QML interface" (which by the
way has subsequently been removed from the mainline gramps
code).
In the same commit, in cli/clidbman.py, he added an
_errordialog function and an "ERROR = _errordialog" line,
evidently so all DB errors, no matter whether in GUI or CLI
code, could be changed to things like:
ERROR(_("Could not rename family tree"), str(msg))
But then in 16 February 2011 MDNauta, in
7c1b26d969
changed the generic ERROR to either DbManager.ERROR or else
CLIDbManager.ERROR, depending on whether it was in GUI code
or CLI code.
Which of course defeated the purpose of the change to the
generic call, so I have changed it back to the original
ErrorDialog call, directly.
The decision was made even easier by noticing lots of
more-recent error-handling code which used the ErrorDialog
form as opposed to Benny's variant.
cli/arghandler.py went from 8.30 to 9.52
cli/argparser.py went from 8.43 to 9.74
cli/grampscli.py went from 7.99 to 9.29
cli/plug/__init__.py went from 7.63 to 9.69
The problem is that "nearby" comments are put into the
gramps.pot template, to aid the translator, but these
comments are referring to an untranslated string, which
then confuses the translator, who wonders if the string
flagged for translation should be translated after all.
The solution is to move the comment futher away, so it
is no longer "nearby" the translated string.
http://gramps.1791082.n4.nabble.com/Fw-Translation-question-td4676138.html
This fulfills both feature request 5902 and feature request 8297.
It adds the D'Aboville numbering system and the Henry
numbering system to the Descendant Report, as requested.
It also adds the Modified Henry numbering system to both reports.
