* some Russian translations updates
Новый перевод для неких случаев, но улучшающие понимание и выглядит более уместно. Также применены русские переводы слов, которые использовали до того англицизмы
* Navweb: Don't use media regions in some case:
- If we don't show families
- If we don't show events
Fixes#011500
* Navweb: side effect between event and media pages
When a media is processed in the media display section for an event
page, it's remove from the media_list, so when we try to create the
media regions in the media page, the media list is empty and we
can't display the regions.
* Narweb: Don't show the regions for a thumbnail
* Fix import file chooser filter to accept upper case extensions
Fixes#11463
* Allow import file filter to accept case insensitive extensions
Co-authored-by: Nick Hall <nick-h@gramps-project.org>
Fixes#10124
Fix up Event Editors Place display for bidi text with Gramps ID (PR 924)
Some versions of Gtk/Pango have trouble with text containing both LTR and RTL characters. The bug notes this shows up in our Event Editor on the 'Place" field, where we have the place displayer title and the Gramps ID concatenated into the same string.
In older versions of Gtk (3.18.9 tested) the bracket around the Gramps ID would get mangled to the beginning of the string:
<images>
In newer versions of Gtk (3.24.3 tested) it was better to start with:
<images>
The older version of Gtk/Pango doesn't seem to properly interpret all of the potential Unicode bidi control characters, so the fix shown is the best I can do. The fixed version of the newer Gtk version is what is desired.
I note that the Place displayer should be fixed up to use more appropriate separators than just commas for RTL text, but that is another issue.
Fixes#11410
The bug submitter noticed that the GEDCOM export contained translated strings in the MEDI lines of his export. GEDCOM should contain English values for most such cases where 'types' are exported.
I scanned the export code for other potential cases, and found:
* Certain unexpected event types on individuals (Marriage)
* Certain unexpected event types on families (Immigration, Residence, etc.)
* Pedigree types that were not standardized on PEDI,_FREL,_MREL (Sponsored, Unknown)
* Family Attributes other than Number if children (Caste, Description, National etc.)
* Personal Attributes other than Caste, Description, ID, National, number of children, SSN (Occupation etc.)
* The MEDI types of this bug report...
Fixes#10762
User "petpil" (Gramps Bugtracker) noted that the Calculate Estimated Dates addon would not expand the size of its window content when the window was stretched. That addon used the ToolManagedWindowBatch which uses a Gtk Notebook to support several tabs. He also submitted a patch which fixes the problem.
The Gtk.Container.add method originally used apparently did not have expand/fill settings to allow the expansion. The Gtk.Box.pack_start used instead does.
I tested this with all the users of ToolManagedWindowBatch and ToolManagedWindow which inherit from ToolManagedWindowBase, and did not see any bad/unexpected side effects. The Calculate Estimated Dates addon was the only one that really could use this, as it was the only one which I spotted using a potentially large widget in the notebook tab.
* Max ages should be divisible by 5 to avoid out of range
errors.
* The chart width should be greater than 45 to look right and
avoid division by zero errors.
Fixes#11384
It turns out the changes was actually changing the wrong config setting...
I had to look this one up. Using a lambda like this is called a 'closure' by some; what is happening is that the value 'constant' is being evaluated at the time the lambda is called, not when it is assigned. So in this particular bit of code the preference setting was actually changing 'preferences.family-relation-type' (the value of the variable 'constant' set a bit after the lambda definition.
I reverted this particular bit of code, as I think this kind of Python knowledge is pretty obscure (I could have just used a different unique name for the 'constant' variable).
Fixes#11390
As it says, if Family Tree name contained non-ASCII characters, the titlebar on Windows would display it wrong. Turned out to be reading of a utf8 file without the 'encoding' set. On Windows this results in using the default encoding which is one of the code pages, NOT utf8.
that passes
If user has only a single font available that passes check for the Genealogical Symbols being all present, the original code crashed. Apparently never tested... #598Fixes#11395