And in that case, you won’t see much of it in a report, which is why I put a site like Wikipedia in the source, and the page name in the … page.
That’s right, and it would be nice when it’s clickable in source and citation form, and for me it would be even nicer when I can use the context menu (right click) for that, so that I can see the source or citation right from the sources and/or citations view.
The plugin approach would allow anyone to write a CSL formatter.
We would allow the selection of a custom template.
I would suggest using citeproc to do the actual formatting.
CSL support Translation templates.
So it is easy to create translated key-names.
What is stored in the json or xml file and whats visible in Gramps GUI can be totally different languages, input/output can be different etc., etc.
This has been explained to you multiple times in the past.
The CSL xml language syntax is also based on Relax NG, same as Gramps if I’m not mistaken.
2 Likes
Wikipedia appears to have an adaptive URL rewriting rule. If you leave out the language qualifier, it falls back and checks for a language variant. It might only do that for “en” or the OS Language. So I try to strip off those subdomain qualifiers from my URLs.
It does something similar for mobile vs. Desktop CSS. Browsing from my phone always transforms a “https://wikipedia.org/…” URL into a “https://en.m.wikipedia.org/…”
I wish we could do the same with our MediaWiki powered documentation. It would be so much nicer if the internal Search only found the master page instead of all the language variants.
OK, thank you. I really did not know about these locales, and I do see that they need some work, because most terms don’t have a proper Dutch translation, but that can be worked on.
Also, when we can use the citeproc for Python, there may be no need to load these locales separately when we use CSL in reports.
This suggests that we may only need to read the locales inside Gramps to make sure that the labels in our citation dialog(s) are shown in the right language. We normally rely on other resources for those, but I assume that this can be done.
Can you elaborate on that @Nick-Hall ?
I can’t find any technical documentation for citeproc. The prototype I wrote took code from the examples.
We can always extract translations from the CSL locale files if necessary.
I have created a draft pull request #1402 to investigate this further. The code needs tidying up, but I have something working.
1 Like
I totally agree with you in this Nick.
And CSL also support translation files (locals), so most of the features needed for Gramps should be available in the CSL “world”.
- Templating
- Translations
- Open source and free format for data exchange and structure
- Possible to submit a Citation Style with both templates and translations, to be used in other CSL enabled software.
And even if supporting CSL fully, only the attributes/properties used in the source file imported/read needs to be created as a Gramps attribute key pair.
is this what you are looking for?
its citeproc-js, but still?
https://citeproc-js.readthedocs.io/en/latest/
This is something I found for citeproc for python (cyteproc-py), don’t know if it is of any help.
https://openbase.com/python/citeproc-py
Similar to the Place Enclosed By tab, could Sources do something along the same lines.
Source A: Periodical Title
Source A1: Volume 1
Source A2: Volume 2
etc.
The sub sources could only be enclosed by 1 superior source record. (Unlike places that can be enclosed by multiple places.) Instead of setting an enclosed by date (ala places) the enclosed by reference would a Reference Type. (Periodical, Multi-Volume Set, etc)
The Source/Citation entry would build its Source Tile from the Source hierarchy from largest to smallest and take the Author and Publication information from the smallest source which holds the citation record.
The Source views would need to have a multi-level Source list as well as the current single layer source list. In the single layer source list, the displayed Tile would need to be the combined hierarchy title. Move the Citation Tree from Sources to Citations ??.
Since the time Nick responded, this is what has been churning around in my head.
@DaveSch I’m just curious, would you do that for all periodicals (even newspapers), or is it just for the sake of managing the large PDF files that you mentioned earlier:
I suppose that things like Newspapers and magazines could be set up with layered sources. However, there would not be too many of these situations and it would still be easier to add the issue information to the citation. Especially where any source image would be unique to that citation. And most of my newspaper citations are of transcribed obituaries in a Note. As notes do not have citations, I just add the information to the end of obit.
I have many sources that I have PDF copies of the book so the goal would be to have a sub source for each volume’s PDF even for the example I gave of the one source with four volumes.
I can also see a main source “U.S. Federal Census” with each year being a sub source. And while I cannot see the need for more than one sub-source of a main source, I am sure others could see the possibility of sub-sources three or four layers deep.
I know a few examples of such deep hierarchies indeed, and they are supported by GEDCOM X, but in all cases, I find that I can also cite them by naming the top and bottom leverls, and a multi level call number, like for this document:
For this document, the middle level, named FAMILY, is represented by the F5 in the reference number D1809/F5/1.
This means that for me, the need is not really there.
When you look at the examples in Evidence Explained, or the fields stored by reference managers like Zotero, you will also see that there is not much need for a multi level approach, because you can simply use different fields (or variables) to distinguish between the names of the archive, the collection (or magazine, or newspaper), and the item or article, and most of these fields already exist in CSL.
Not only is does the “Volume/Issue” vary for Periodicals (newspapers, magazines, newsletters) but so does the Author. And the Editor varies too over the lifetime of a publication.
(I still really want to see the ability to link a Gramps Person as the Author, Editor, Publisher. Seeing the whole collection of books by an author or the relationship of the Author(s) to the subject of a book can be enlightening.)
H’m, if that’s the case, there are more reasons for a flat model, because any grouping under a single object will hide the variations over time. So that’s an argument for EE, or Zotero, with enough fields to store all titles and other fields as they are seen in the wild.
Any yes, I remember the “Authors are people too thread”, which makes sense.
But the odd thing is, that there are all sorts of things that people really want, and it seems that the more we want, the less we get done. BetterGEDCOM started in 2010, and accomplished nothing, FHISO is quite old too, and shows that its members don’t really understand how you get things done in the real world.
This is a bit like the ISO network model with its 7 layers, which I can still find in an old book that I bought, by Andrew Tanenbaum, an English professor working for a Dutch university, who also designed Minix. The ISO model never took off, because we already had something that worked, which was called the internet. And the same is true for the ISO trying to push a standard for Unix, called POSIX, which also never worked. And the fun part there is that Tanenbaum’s Minix inspired Linus Thorvalds to write Linux, which did take off, especially when a South African entrepeneur pushed Ubuntu.
And this suggests that we can only move forward, if there is some big guy pushing it, like Bill Gates did with Windows, FamilySearch with GEDCOM, and people really wanted to have it, like they also wanted SCART, which was forced upon us by the French government, or USB, or phones running on Android.
And that’s where reality hits. Real people like our Aunt Martha don’t want Clooz, or Evidentia, or Centurial, or Evidence Explained. Two of the most popular genealogy programs here in The Netherlands still use the model where you put a short line of text behind the SOUR tag.
And I know from discussions in a local FB group that people really like that!
So, what’s next?
I thought of this. The Source Title would build from the hierarchy from top to bottom. But the Author and Publication information for the source/citation entry would come from the sub-source that would be the source record used by the citation record.
2 Likes
What I would like (and what I realize many others may not like) is the ability to reference well-established external hierarchies of place data and source data, rather than having to duplicate all of that effort.
3 Likes
I agree. This discussion seems to be creating a Source Hierachy which gets more and more complicated. I suspect that the majority of Gramps Users are not interested in that level of complication.
The one thing I did find from this thread is that creating a .gramps file of a subset of the Family Tree will cause all citations of a selected Source to be added even though only one Citation is needed. Fixing that would be good.
1 Like
A source hierarchy would provide the flexibility for a user to create sources with any number of levels. Although I suspect that most users would choose to use one or two level sources. At the moment we have a fixed two level (citation-source) structure.
However, to start with, I suggest that we focus on the idea of citation formatter plugins. I have already written a “Legacy” plugin to provide our existing functionality. Now we can think about other plugins, perhaps based on either CSL or templates.
The next step is to think about what citation variables we need and how we want to enter them in the GUI.
2 Likes