With this commit, two more reports now show a year as an
ordinal number in Croatian, and a year I missed before in
webcal.py is now fixed.
This commit also reverts the Croatian ordinal year fix in
the gramps50 statisticschart.py since upon reflection I
feel it would be better done in master, since then our
translators will have until 5.1.0 is released to do the
two new strings the fix requires.
Issue #10822
I ran gramps with a fresh copy of the example.gramps tree,
then ran the Complete Individual report. The options which
matter are "Entire Database" and "Include Notes" but I also
included the gramps-ID since that speeds up my work.
Then I noticed that hundreds of names at the end of the
output file all had the same note (N0001), whose text said
it referred to a specific person.
So I looked higher and the note inclusion started with I0044,
the default person. It was real for him but not for the next
person after him, or all the people after her.
I introduced the problem when I fixed 10033, in d6a97cf90e.
Note that this bug is independent of the CIR fix in p.r. 676
and still happens even after that pull request is applied.
The place-format option was added to the Detailed Descendant
and Detailed Ancestor text reports in cbac98894b
But those two reports use the Narrator class to show many of
their places (and dates), and that class was not modified to
use the user's custom place format.
So if a user had created a custom place format and ran
either of those two reports, their places would be shown
inconsistently. This commit fixes that.
(The non-detailed ancestor text report also uses Narrator to
show its places but that report has not had the place-format
option added to it, so this commit doesn't touch it.)
When I started investigating 10822, I saw some Croatian dates
didn't seem to be working in 5.0.0, to my surprise. I believe
I fixed that in the previous commit.
With this commit, the three reports now show a year as an
ordinal number in Croatian, so I consider 10822 fixed.
If there are any additional problems displaying Croatian,
please file additional bug reports ("one bug, one report").
Fixes#10822
When I started investigating 10822 I saw some Croatian dates
didn't seem to be working in 5.0.0, to my surprise. There
seems to have been some kind of regression from 4.2.8.
But the Croatian translation for gramps hasn't been updated
in about three years -- except by non-Croatians. So I don't
know why some "translated" strings which control how dates
are displayed were disabled (marked as "fuzzy") in this:
6c67053e1f
Also, I saw some code in the 4.2.8 Croatian date handler
which was not in the 5.0.0 Croatian date handler -- somehow.
So I believe this commit fixes the Croatian date handler.
Issue #10822
* Webcal: link problems in some cases
Year 2016 is highlighted by default instead of current year.
Fixes#10801
* Webcal: Missing links when muliyear unselected
Load data.gramps, start with the default person (I0037,
Edwin Michael Smith), run Family Descendant Tree, choose
"Start with the parent(s) of the selected first", hit OK:
.../descendtree.py", line 881, in start
family2 = self.database.get_family_from_handle(family2_h)
...
Or start with I0057 (Anna Louise Smith), run Family Descendant
Tree, choose "Start with the parent(s) ...", hit OK:
.../descendtree.py", line 773, in start
family2 = self.database.get_family_from_handle(family2_h)
...
Fixes#10811
There is already a check in the MonitoredDate class for years
which are more than one year in the future, so such a date is
already going to be shown in red.
But some locales use the "datetime" library to parse typed-in
dates and that has a maximum year of datetime.MAXYEAR, 9999
currently, so dates greater than that produce a ValueError.
Besides adding checks for that, I have also made it so that
locales which don't need that library don't use it.
Fixes#10815
Fixes#10754
A bit of history. bug 2060 was filed a long time ago (2008), and a patch was added to close it in 2016. I believe that the bug had already been patched by then, although I cannot be sure. The patch caused the Gramplet to update anytime the active-changed signal occurred on a person view. I suspect that this caused a fair amount of overhead on very large dbs as the entire person list was rescanned.
In any event, Doug Blank recently removed the original scan code, as well as some useful functionality. And left behind a bug where a value was always zero. The users email list had some complaints about the lost functionality, and I also saw some recent complaints that the gender statistics were incorrect. Turns out that the db's genderstats data was incorrect, probably due to crashes after db updates. The Genderstats don't get saved until db closes normally. In addition, running the Genderstats rebuild tool, did not immediately appear to correct the situation, Gramps had to be restarted to show the updated results.
I added the original statistics code back into the Gramplet, suitably updated for 5.0.x. So the Gramplet no longer depends on dbs genderstats, it scans for it now on its own.
I removed the update on active-changed function, so overhead is only present on actual db updates (which have their own signals). I tested that the add, edit, and delete person changes do properly cause the statistics to update now. So the active-changed signal is not necessary.
Fixes#10783
Check and Repair tool doesn't fix bad references when the reference handle is an empty string.
Found when rewriting the backlinks scan on same tool. I assumed that the prior checks had already corrected any bad forward references, and did not put in a test for them in my new code. The Travis test failed and when I debugged, I found that the tool had an exception on a handle that consisted of an empty string.
Its interesting to note that when I changed the code, a lot more citation and source references were fixed in the test.
Fixes#10618
* Speed up Check and Repair, backlinks check stage.
* Fix Check and repair; backlinks scan to deal with bad references
which should have been fixed in earlier checks!
Python 3.6 and above has deprecated illegal string escape sequences. Escape sequences are preceded by a '\' and valid ones are "\n\t\r" etc. Illegal ones are not in the list https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals.
Previous to Python 3.6 these illegal sequences were ignored and the '\' was left in place. Pylint has been noting these for a while now.
This PR corrects these sequences in Gramps. I used
find . -name "*.py" | xargs -t -n 1 python3 -Wd -m py_compile 2>&1 | grep Depre
to locate the failing strings.
