But I have tried to create pdf and odf-files, with and without checking this checkbox, with long and short notes but I don’t see any differences between the files.
Does anyone know how to use this option? Or does it simply not work?
Thanks in advance!
It is working correctly for me. I am on 5.1.2 on Win10. I see you use 5.1.2 but on Linux Mint 19.3. I am wondering if someone with the same OS can replicate the issue so it can be narrowed down.
Thanks for checking! Actually, I am working in Linux Mint 20, so I’ve modified my settings
But, what differences do you see exactly? I have tested the same on Win 10, v5.1.2 and when I create a Complete Individual Report with output to OpenDocument-text I really don’t see any difference in both documents (one created with checkbox checked and one not).
I have created a person with two long notes and I expected that the second note should start on a new page when I check the checkbox. But the second note is placed directly under the first one…
… And then it worked !!! I was looking for a person with some quotes and yes, they will be placed on a new page or not when the checkbox is checked or not.
Then the English text here is completely wrong according to both the Merriam Webster (American) and the Oxford dictionaries (British), it should be written as ‘endnote’ and not as ‘end note’.
I am working on translating Gramps into Dutch, and unfortunately I am regularly surprised by this kind of carelessness.
Anyway, thank you very much!
Yeh, My fault there, I was thinking about “Endnotes”, but forget to use both “End note” as reference to the question and the “Endnotes” as the correct terminology …
I have seen that error in multiple computer language dictionaries and world lists before, I think its a common error to split word, and a few spellcheck libraries has the fault “built in” …
And not only for this, but a lot of other words that shouldn’t be split in English …
In general, you may find that many people consider issues of grammar and correct wording to be ‘picking nits’. Particularly since the first language of many of our Open Source programmers is not English - British, American, Australian or other dialect! So long as the Output is OK, most programmers would rather spend time on what they consider ‘Real’ problems. They don’t even notice such subtleties.
For most programmers, the dopamine reward comes from adding new functionalities or in solving complex logic problems. The details of interface, documentation, and error handling tend to be aggravations. (In one program that I wrote personally, the basic functionality of the program was complete in about a week with about 3,000 lines of code. The idiot-proofing & documentation made the program 10 times larger and took more than 6 months. Instead of a half-day of training on a 1-page of set of complex instructions for 4 people refreshed once a year during a 5 year project, I spent 6 months coding dozens of iterations of the program with the specification changing due to a weekly hour-long meeting with 7 people!)
As much as we need programmers who address New Features & Bugs, we could benefit from the detail-oriented people becoming direct contributors too. (This includes those who see language issues and the little GUI idiosyncrasies.) If they can submit corrections for the Gramps code directly, these fine-tunings of the interface & output could be completed by people who find such work gratifying.
Maybe this would appeal to you? (In addition to the much-appreciated Dutch translation work!)
Personally, I contribute by trying to research & find answers for the support maillist or Discourse. I also work on the Wiki. (Revising the Wiki tends to inspire me to file far too many bug reports & detailed feature requests.) It is my way of learning the program – I found the Wiki conflicted with my learning style.
My contributions are still limited because I have a VERY uneven understanding of the features of Gramps. I don’t contribute to coding because I found Python & GitHub unappealing. (I expect my aversion to Python will weaken and I’ll start coding a few items that I need but others do NOT… Plus I won’t have to follow coding standards for stuff that isn’t distributed!)
I’m not so sure Gramps programmers don’t care enough about the language. Precisely because they often deal with genealogy themselves. But a language error is made very quickly and you often overlook it yourself. That is why, as you have noticed, people who test the result are so important.
And I think that should initially be people who, because of their origin, are completely proficient in the primary language in which the program is written. For Gramps, this should therefore be English-speaking people so that the translators can focus as much as possible on their own language.
Nevertheless, I do like to not only translate texts, but also repair small imperfections. And I’ve been busy with that from the moment I started translating the addons. Because with several addons, the translation did not work at all during testing. And that is due to outdated Python code in these addons, so the translation will no longer work in any language except English.
But there is more to it:
Sometimes words or sentences are not offered for translation, you will only find out after very extensive testing (for example in reports).
Sometimes words or sentences are translated in Gramps core itself. Apparently Gramps core has taken precedence over the addon translation, I think this should be the other way around.
when I perform a repair on an addon, words are changed or whole sentences are added. And that has consequences for all translations, so I give other translators a lot of work…
)