this already exist in style formats like CSL (CSL Json as fileformat), RDF/OWL (i.e. json-ld) or bibliatex (bib)… the ontology already exist, so why not use it?
the field are already named, but there are more field than some in this discussion want it to be.
even graph format like graph-ml or cytoscape json, can support most of the existing ontology as attributes for both nodes and edges…
But in difference in having to write the same information multiple times if you use different tools, by have support for existing file standards, like CSL JSON, JSON-LD, and style standards as CSL or Dublin Core, you can actually use data entered in one software in another software with minimal converting work, it might be you need to define a few fields/attributes, but most of that work will be done in the software, not as a transcriber script or a huge amount of work in Openrefine.
Okay but I don’t want this (now). I’ve thousands of filters I’ve defined and I don’t want to change all my sources and citations on which some of thes filters depends on.
You wouldn’t need to if an implementation is done correct, it wouldn’t be any different from what you talk about, it’s just support for a style standard and a file format that is already used, it’s not a big change in the source and citation structure of the base database…
In the simplest form, its just a form gramplet that put data from different fields into the existing fields of the standard gramps, but it format the text in those fields in a standard style that you as a user can choose (i.e. Chicago, APA, or any other standard, or if you like, you can define your own custom CSL Style and use that, so your string of text in will be exactly as you want it to be, only difference from “inventing the wheel again” is that you can import and export sources and citations you already have in a Reference Manager (for those that use one) to and from those software… I honestly don’t understand why people is so scared of interchangeable formats and interoperability between different software.
Well, the reason to object is quite simple. And that is, that, when you import CSL variables from whatever format into source attributes, you’re not done, because the attribute names are in English, so they won’t make sense to users that use Gramps in another language, unless you translate each and everyone of them, or map them to existing variables that already exist in our data model.
They will also not appear in reports, unless they are mapped to existing or new variables.
I learned that most people on our lists, and other lists, ignore this, because they’re used to the English language for their own purposes.
Note that the full CSL specification has a lot of variables, meaning that we have to find mappings, new variables, and translations for dozens of new ones, and design screens where they are presented to our users in a meaningful manner. Just adding dozens of attributes is very unfriendly to our users.
I also made another test with zotero, just to check what you wrote about the Norway archives, and the truth is, that the Norway digital archive site provides source data that is quite similar to what I can see on Dutch, German, and English sites, meaning that it does follow the standards used by professional archivists and genealogists, and not by ‘general’ scientists. And as expected, these meta data are not recognized by zotero, meaning that it’s still useless for serious genealogists, who are not interested in MLA, or any other alien standard, but in compact citations that work in local magazines.
To keep things consistent, and manageable for users and translators, I think it’s important to restrict the number of extra variables, and not simply import all the ones that may be present in a CSL file, whatever the format.
In concrete terms, this means that we may add variables to describe the so called ‘fonds’, as described on
and add some so that actual volume, page, line, and similar numbers can be stores in a language neutral manner. Common abbreviations like vol. and p. are not language neutral, and for these CSL has proper variables.
Only for some of the transcribed data, and that is because me and a few others have asked them to do so, most likely that will again be changed for the next “version” that is developed now, and that will be the 3rd different “type” they provide, all the past is broken, and that’s why I say they don’t follow any standard, the Swedish national archive is a litter better, but the local archives, is hopeless, even the big ones like Stockholm…
And please make up your mind, is CSL or Dublin Core useless because it is to limited or is it useless because it support to much… or is it just because you have set your mind on that it’s useless.
None of your arguments stands, because anything you have tried to show me is thing that I easily can do within CSL or Dublin Core… but if you feel better, support RDF/OWL, that would be great, because that is actually linked data, and something I have asked for multiple times.
You write about creating or mapping attributes and/or variables, as if you wouldn’t need to do that when using ontology from schema.org or any other standard other than CSL, but the fact is that there will be exactly the same amount of work mapping attributes/variables, regardless of what “standard” you use, and if you don’t use any standard, that also will give interoperability or interchangeable data, you are back to inventing the wheel all over again.
And you talk about “serious” genealogist, as if that is some higher class than i.e. DNA and biology researchers or archeology, or historical research, when the truth is that it is a very, very narrow niche, and there is no serious standards except the overloaded EE regarding citing sources, in the over 25 years I have been doing this, those so called serious genealogists has still not managed to create one simple standard for sources and citations that are interchangeable, While the not so impression biologists, archeologists, historians etc. actually have used a common standard for decades.
And the “Fonds” you link to… it can easily be managed, as an EXAMPLE, Zotero use Collections, so you can sort them, and you can use the extra field to add ANY key pair you like, and if you want the collection hierarchy to show in a style, you can actually create your own custom style, but again this is JUST ONE Example on how another software has solved some of the problems that have occurred over time.
and if you have seen anything I have written, I have multiple times wished for hierarchical registration of sources in Gramps, similar to Places, and the same for Events (Main - Sub Events)…
And Regarding “forms” or multiple “text fields” for citation and source registration, I don’t need that, but I do understand why people that don’t use external Reference Managers want some kind of Template Based system, but even though I find them extremely limiting, I don’t walk over my dead mother to find arguments for how useless I find them.
Just for once, try to take of your blinders and think how other people use software and what other people find useful, there are actually a lot of people that find information not only in an Dutch Archive.
The translation needs to be done regardless of what you do, and it is less work translating a vocabular that already exist, than inventing new expressions all over again. And for user customized variable- and attribute names, there are no translation in the first place, so your argument doesn’t hold!
Just a hint, if the style you want is not present, you can either edited an existing one, or create your own by using a CSL Editor, as an EXAMPLE: Zotero has two ways of editing any of the over 10000 styles that already exist in the CSL repository, but you can as well use any xml editor or any plain text editor of your choice.
CSL support localization, and have those for the most popular styles in the repository, but there is not a problem to create them for other styles, even your own custom ones: Home · citation-style-language/locales Wiki (github.com)
So as you maybe can figure out if you actually read about this, there is no problems at all to create a “Gramps Citation Style” and use CSL as the style language, it can even be published in the repository by contributing the new style: styles/CONTRIBUTING.md at master · citation-style-language/styles (github.com)
If you like and get permission from the Author, you can actually create ALL of the definitions in EE in CSL, or you can create a style for the archive standard you like the best… and if you want it localized, you just provide the localization with your new style.
You must stop azuming that Zotero and CSL is the same thing.
I get your points, and the one thing that I try to avoid is investing time in things that are likely to get too big, for me, or for translators. That’s why I prefer to use a subset of the variables that exist in CSL, and not support an import of everything that can be exported, by any type of reference manager.
The idea of something being too big, is sort of subjective, but since we depend on individual developers to work in their own time, not their bosses’, there is no practical alternative for that. That means that I will not invest time in importing all possible variables that can be created by a CSL compliant tool. It also means that as long as reference managers don’t detect the fonds meta data automatically, they are useless, for ME.
When I read through the variables, the ones for archive, collection, and series can be used to store most of the things that I want to record in a citation, and it looks like the locator is also flexible enough to store references to pages, folios, and lines, etc.
W.r.t. investing time, my preference is to add this reduced set of variables to Gramps, so that I can enter this type of meta data into Gramps itself. Importing everything from CSL into citation attributes is not enough, because that makes things invisible for users that don’t understand English, and IMO it is a can of worms anyway. This is why I don’t use the forms Gramplet either. IMO, that also is too much of a mess.
Supporting (a subset of) CSL will have the consequence that in some ways, Gramps will be less GEDCOM compliant. And that is somehow similar to RootsMagic, which has the most complete support for EE that I can find.
Some years ago, I used some SQLite tools to read the RootsMagic database, and found that they have more than a thousand different templates, most of which are based on EE, and that number is one of the reasons why I objected to the implementation of our GEP to introduce EE like citations. Copying the RootsMagic templates would be illegal, and even the subset that is in the public domain is so large, that I don’t think that we will find enough volunteers to translate that. Moreover, the variables used in that are a chaos, so even translating the variable names would be quite a big job.
Personally, I’m mostly interested in recording the meta data, not generating formatted references, and if there is any tool that makes recording that meta data easier, by scraping the web pages of the archives, I will probably use that. That is why I tested zotero on a few sites, where it didn’t see any of that type of meta data. And that is something that I understand, because its main use is in a scientifiic environment where people publish ‘papers’, in (electronic) magazines, and for those, the hierarchy is much simpler than the one used in most archives, including the national archives in our countries.
I’m assuming, but haven’t tested, that JabRef and other open tools don’t detect more meta data than Zotero, because they come from the same background, and without automatic detection of that, I prefer to enter these data directly into an expanded version of Gramps, and not into a reference manager, which requires that we write an interface for that. And I repeat that, even if we write such an interface, we must still have a user interface to edit these in Gramps itself.
I also think that implementing full CSL in Gramps, meaning more than just the variables that I and a few others would like to have, and including the generation of formatted references based on CSL definitions, is a lot of work, and may not be helpful to the average user, who is not a scientist.
Note that, when criticized (by me), Elizabeth Shown Mills has written that EE was never meant to be automated in the way that it was done in RootsMagic. That is, because she is not a software developer, so she never really thought about optimizing variables like the CSL authors did.
In any case, ALL of the definitions in EE is a large number, and I think that it’s bigger than we can handle. RootsMagic has most of them, and has its own definition language, which is much simpler than CSL. And for RootsMagic things are much easier that for us, because they have more money, and their program has no translations.
For me, personally, supporting full CSL is way more work that I will ever gain in time, but of course you are welcome to expand Gramps if you think that it IS a good idea. That’s why it’s open source.
To me, it looks like you refuse to accept that you can’t convince me with repeating the same things again and again. I make my own decisions, and I only invest time in software when it makes life easier, for ME. And if it does, I might share it, knowing that I might get time saving features and tools from others in return.
For me, using an external reference manager does not make life easier, unless it does what I want out-of-the-box. Modifying Zotero to detect more meta data and adding a CSL like interface to Gramps is way more complicated than adding the meta data to Gramps right away.
Another thing is that you also don’t seem to accept that my software engineering principles are different than yours. IMO, using attributes for this, or for the forms Gramplet is plain wrong, and good software should never use that kind of tricks.
Of course, other developers may have different opinions, so if they want to jump in, they can do so.
But if they don’t, you have to make a choice of making the right changes yourself, or choose some other software, like I chose to stay with Gramps version 3.4.9.
I also don’t buy the idea that we must change Gramps to make it more acceptable to so-called scientists. I am a scientist myself, and I am smart enough to choose my own tools, and to decide whether I can improve them, or convince others to make changes, and to detect whether that strategy really works.
This is a sample of a hand-built source listing from my 1999 genealogy website. It’s the sort of thing I’d like to be able to generate eventually through Gramps –
At the top is a Card Catalog drawer for this particular “Type” of source (a book) … my website logo is normally beside it. (Click the drawer to ‘put it back in the cabinet’ and be able select another drawer.)
Along the right is the Source thumbnail. Click to download the digital version file
In the center is a MARC database listing describing the source.
The card at the bottom is generated dynamically. (Using a sweet tool by John Blyberg.) Initially, I thought it would only be added for visual distraction when no there was no thumbnail (or digital copy) of the source.
And here’s a partial listing of the catalog drawer for a ‘Serials’ source type:
And it looks like you refuse to admit that you are wrong regarding CSL, and for that reason generate lies about how useless it is!
You seems to refuse the thoughts that other people manage to do something with a tool you can’t and because of that, you spread negativity and falseness about the tools you don’t like!
I know it is a common thing to do in many Open Source project, but I hoped that attitude was kept in the dev mail list on this project and that people actually could discuss solutions for new features or ways of doing things here without a few extremely negative developers telling them how stupid anything they try to suggest is, because some “i like it the way it is”-developer is not interested in changes.
Same went on with the feature request for Places, and Places as Subject for Events.
Same went on with the wish for Main and Sub-Events.
Same went on for regarding support for a few interchangeable file formats, and even when some users (including myself) asked for better CSV export and import.
Same have been the case for multiple question for updates of old files and drivers (specially when it regards AIO for Windows and MAC)
Same regarding the possibility to use native Python on Windows
And the same when some people ask for additions or changes to reports or adding/expanding graph views.
It seems that some few developers and “inner circle” users, specially those on Linux, don’t want Gramps to be anything but another genealogy software without any attractive features outside their own narrow registration of family information.
That one you can actually do with Zotero and the markdown export plugin… Problem will be to link it to your Gramps generated html files.
Just add the variables/attributes/keypair that’s not in the template to the extra field and create a template that use those variables for the markdown plugin, it will export a text file formatted in markdown exactly the way you have made the template file.
I create something similar from Zotero to Obsidian and Foam nearly daily.
And I can add Notes and annotations to both the Citations and the Source itself if I like to.
If I i.e. have a huge City Directory in a pdf that I have annotated, I can extract those in Zotero and use the Notes in Markdown with links beck to the correct page and line in the pdf.
There is also libraries that can do this for image files, but I have only found them for use on web sites.
If Gramps supported CSL (NOT ZOTERO INTEGRATION), it would not be that hard at all, you could use pandoc with a template or citeproc.js, and one template would be enough for use in multiple other software.
It can be done with RDF/OWL also, but the bibliography extension for it is aged (2015) and the same extension is used by the schema dot org extension for bibliography.
When I read this, it still supports my idea that we can only make progress by adding a small number of variables that can store the types of meta data that we can agree on. Some may be inspired by MARC, others by CSL, but I don’t see any reasonable way to support all variables of any existing standard, except for BibTex maybe, but BibTex does not include the meta data that we can find in the archives, i.e. those that support the recording of fonds, which I consider to be essential to create citations that are more readable for most of us, and that are accepted by local genealogical societies.
Building a full interface that imports all variables that can be possibly created by Zotero, or any other tool that writes some CSL format, can create so many attributes, that we run into the same problem that we had with the EE subset, meaning that the result is too big to be translated to all supported languages. We ran into that with the Yates templates.
Please keep in mind that tools like Zotero support far fewer languages than Gramps itself, so that they are not a realistic option for most. IMO, every user deserves good citations, and that means that the ones that are most common in the archive world must be supported by Gramps itself, without dependance on any external program.
Zotero, Jabref and other open source Reference Managers support the languages that users and developers chose, just as Gramps.
At the moment Zotero support 41 languages for the interface, and it use unicode so you can use any language you like for your metadata, the CSL Citation/BibliographyTemplates can be translated to any language and the templates can as I have tried to tell before be customized.
Jabref support approx. 20 languages for the GUI.
So I don’t think you can say they support less languages than Gramps.
The only thing Gramps need to support is import of the CSL XML schemas for the different Citation Styles a user want, it can store the complete schema as a json serial string or as Gramp Attributes, in the same field used today, and the gramplets can easily make the variable/attribute names dynamically, just like the Forms gramplet do. The variables will be added dynamically, so if a user chose a Style with 20 variables, there will be 20 attributes for the citation, if the user chose another Style for another Citation/Source with a totalt of 50 field, but where 15 is shared with the first, it adds only the 35 extra that is in the CSL XML or CSL JSON (citeproc.js) file.
It will be up to the user how many variables/attributes they actually add to the database, Gramps only read the variables from an XML file and display the attributes dynamically for each source and citation.
The only then actually needed is to define what’s source metadata and what’s citation metadata.
No field that is in Gramps today needs to be removed or changed, the main display of both sources and citations should be a simple as possible, and the attributes can be displayed in a multi line text box in additon to the “normal” attribute editor.
There could even be a user configurable variable to attribute name mapper, so the developers don’t need to do that job… and anybody that don’t want or need to import/export to/from CSL or Bib can just add attributes as they please, or use the fields that is in Gramps today.
I do know that it is a job to create this, but it is less job than creating the whole thing from scratch and find good names for the attributes/variables…
And again, the benefit would be and interchangeable format that is supported by a huge amount of software, from writing to web to IDE to Mapping and Graph tools… AND the libraries for Python already exist.
It is possible to create those GUI’s in VBA, so it should be possible to create it in Python, GTK, QT etc, relatively easy
The whole system can be based on the variables in each single CSL XML and the variabels holding metadata in the CSL JSON.
BiblaTeX/BibTeX is an alternative format that most libraries that support CSL JSON also support, both are interchangeable formats for bibliography metadata, while the Styles is definded by the CSL XML files.
As an example Zettlr support both bib files and json files for the Citation Module.
And again, I am neither asking for nor want software integration with Zotero, Jabref or any other Reference Manager, all I wish for is a few useful interchangeable formats for the data, that can be used in multiple research tools.
Formats that users can use without an extended knowledge of ANY programming or scripting language. It’s called to be a user friendly software i think.
OK, I see what you mean, but IMO, keeping the existing citation variables as they are, and putting all CSL variables in attributes creates a separation between different types of users, and relying on a user configurable attribute to variable name mapper still means that users need to understand English, and I don’t think that’s a good thing. I also know that it’s bad design to implement a single feature in two ways.
I think that for the majority of users, things should be no more complex than as they are implemented in RootsMagic, or Reunion, and in practical situations most people should be able to live with just a handful of templates, and no more than a few dozen variables, and that number is small enough to be translated. An example of these templates can be found on:
If you look at this, you will see that it’s awfully Americentric, just like Tamura Jones wrote about EE, and it’s missing support for the registers that most of us have in Europe, including the UK, meaning the civil registers for Birh, Marriage, Death (BMD), or Baptism, Marriage, and Burial, as they appear in church records. And these registers are almost always archived in fonds, like I mentioned earlier. Defining a handful of variables for those fonds is easy, and it has already been done in the Dutch A2A standard, as it is used by openarch.nl.
As far as I’m concerned, supporting simple templates inside Gramps is easy when we restrict ourselves to the variables that we actually need. A2A is proof of that, and so are Reunion and RootsMagic.
We should also keep in mind that most users prefer integrated environments, and don’t use separate tools for reports or citations. That’s why we have so many plug-ins, and it’s also why developers use IDE’s like Eclipse, NetBeans, and Visual Studio.
Interchangeable formats are nice for advanced users, but I bet that the vast majority is not really interested. That’s why I suggest to expand Gramps itself, and not rely on external tools.
And as a footnote, here’s an interesting discussion on the Zotero forum that started almost 10 years ago:
The site that I mentioned earlier was mentioned here too, 4 years ago, and as far as I know there has been no progress since.
First of, the attributes shall be for any use, for those who want to use them, manually or via a import of CSL.
The language is not an issue, because most of the most used CSL’s is translated in different countries, as an example, the most used styles in Norway is APA and Chicago, and a few made by national publishers, all of them is of course in Norwegian AND English.
Same with any other country that use Citations Styles of some sort, the ones that are most used in the country is usually translated to that nations official language, either by a research lab, or by an university. some are contributed to the CSL repository, but it will not be any problems for Gramps Developers to create a CSL Style and that the Translators translate it and contribute both the CSL XML and the translator file to the CSL Repository.
You try to make the support of CSL to be a lot more work and difficulties than it is…
The ONLY difference from making a “proprietary” Gramps format, is that with CSL (or any other Style format language), the Citations a Source metadata is interchangeable with other research software.
The work regarding fields (Variables, Attributes, key pairs etc.) and translation will be exactly the same.
And if a user chose to use a CSL that is only in English, it will be the users choice, and the request for an translation must go to the CSL community, not Gramps, Gramps shall only read the CSL XML and the translations that comes with it, and as for any other software supporting CSL the way to do the language part is easy, just have a language selector, that shows the languages that is possible to chose from for that style…
A lot easier than that the developers and translators of Gramps must come up with field names for 60 source and citation fields, attributes etc. and figure out what the correct expression for a given variable/attribute should be in each country.
(as an example, Norwegian again, the English “Call Number” in the Repository is translated to the Norwegian “Telefonnummer” - English “Phone Number”, while “Call Number” has nothing to do with a phone, it is in Norwegian “Arkiv referansenummer” directly translated to English “Archive Reference Number”.
We do agree about both “simplecitations” and EE, that’s the reason why I talk about CSL, because it is an internationally used “standard” that a lot of Scholars and researchers use.
The CSL JSON format from citeproc.js, is only a way to store the metadata for use with those styles, but as I wrote earlier, most of the libraries that support this file format, they also support both the BibTeX and BiblaTeX formats…
And, just so it’s clear, it is not only Reference Managers that utilize this interchangeable format, multiple publishing platforms use it in addition to i.e. the Dublin Core.
And as I have written before, the most important thing is that there is support for interchangeable useable formats, not that it is some kind of interoperability with other software.
So if you come up with an interchangeable format that has better support for languages, used by a lot of other research tool, stores metadata etc. etc. it is great, just please start to support interchangeable formats… even JSON-LD (RDF/OWL) will be a huge improvement.
Again, the reason I hold on to CSL and Citeproc.js CSL JSON is because of the support those “formats” already have in Open Data and Open Source communities.
And, seriously, if you want more Python developers to the project, the way to find them is to create features that let people use Gramps in combination with other research software and publishing platforms by providing a few well known and well documented interchangeable formats for data.
Those who not need it, don’t need to think about what CSL is, the can just create their own attributes, or use a minimal Gramps “template”, but if they need a style for publishing something, or if they get a source/citation from some place that is in i.e. APA, Chicago or any other often used citation style, they can just import the style, and use it, Gramps will of course only save attributes/variables that is used by any given set of CSL XML files imported.
another thing that will be useful with something like this is that you can actually use different styles for different types of sources and citations, including different languages, if the settings are per. object.
Regarding usage in Report (including web and any other where a citation is used), is easy, you just chose the Style template and language you want, or use the Template used when registering the citation or source, and the report will automatically format both inline citations and bibliography as defined in that template (usually you only use one citation style in a document, but there is always some exceptions).
So again, the only thing I ask for is an interchangeable format, and CSL is one of the most widely used style languages.
And I know for sure that more and more genealogy researchers have started to use Zotero, and a few have started to use Obsidian, Joplin and other Markdown Notebooks for their research notes.
If Gramps can attract some of those users, there will be more users that can help, and Gramps is still the software that has the absolute best name standard support, it is the best regarding place registration and organization of places, it is the only one that has attributes, and when 5.2 and the feature with registering Events for places comes, it will also be the far best for historical place research (if you don’t use a GIS software).
Interchangeable formats will attract other researchers that don’t want to store their data in the cloud…
I have already had a few asking me for recommendations for software and asked if they could use Gramps after they saw some Graphs i published in a forum, but when I told them the amount of work I have done to be able to use my Gramps Data in other software (mostly Graph software), the thought it was to much job, even though Gramps would be near perfect for their projects…
If you look a little outside the niche of genealogy, Gramps can be used for a lot more types of historical research, but there need to be some interchangeable formats that can be used without the need of creating transcoding scripts, even a full CSV dump would do a lot, because most researchers know how to use Excel, OpenOffice, Number, Panda, or any other similar software, and how to map one column in a workbook to another column in another worksheet, or even simpler, rename some column names.
One of the reasons why there is no progress regarding that Style is because there are just a few genealogy researchers that use have used Zotero earlier, because genealogy is a really small niche when it comes to international research environment, and most of those that use it today find methods to use the Standardized Styles.
And As I have written before, you need to stop write as if Zotero IS CSL, it is two very different things.
Zotero use CSL, and the research lab behind Zotero has supported the CSL project, but that is the only connections between the two.
If the Gramps Project made a CSL Style, contributed it to the CSL Repository, and it had 5000 variables, you could have imported it to Zotero, and if you imported a CSL JSON file full of metadata for that Style, all the “none-standard” fields would be added to the Extra field in Zotero as key pair in the format of “Atrribute_Name: Atrribute_Value”, and when you exported it, or when you used that style for a citation, it would use those.
I do not know how Bibref or i.e. Medeley solve that, but not a single field and value is lost.
This is how it looks for a record from The Norwegian National Library:
I can add any number of extra attributes/variables here in addition to those from the library, and If I need to I can create or modify a style that utilize those if needed.
AND THAT IS THE BENEFIT OF A INTERCHANGEABLE STANDARD, because if I chose to create a style, I can export it as XML, and import it to any software that also use that standard, instead of having to create the same set multiple times.
And there is a lot of people using external software, there is a few using Openrefine, there are multiple that use the sqlite export for stuff, there have been multiple discussions of cleaning data exported in CSV in both excel and Openrefine. And I know about a lot of genealogists using Gephi, Yed and Cytoscape… and also a few using Graphviz to modify their graphical reports…
The problem is, that as long as a software don’t have research and analyzing features at all, and users see the lack of interest for it, they don’t care to talk about it, and what other software they use for that purpose. There is a group on Facebook, where people actually ask for tools outside the standard genealogy software nearly daily.
Jaran, it is clear that you are still missing the point. When I create code to import CSL, there are several ways to do that, but the simplest is probably to store each variable in an attribute. The result of that is, that you get attributes like author, title, and publisher, or maybe to use author-given and author-family, to avoid storing JSON in the attribute value. The latter would be no problem for Gramps, but it may make life easier for users that want to change variables inside Gramps.
In any case, this means that variable are stored as they appear in the imported file, and the consequence of that is that they will appear in English to the user. That is no problem for you or me, but it does make them inaccessable for those that don’t understand English. A good reference manager will present them in the user’s language, but Gramps can’t do that.
Another thing is, that if you put everything into attributes, choosing any name you like, you are not really promoting open data. That is, because true open data depends on shared values, meaning that people engage in an open dialog to reach consensus on the meaning of variables like collection or editor. That’s why a standard like A2A works for us, here in The Netherlands.
Putting formatted text into a variable is like putting the horse behind the cart, because it is not open to people speaking another language, and that’s what I’m talking about.
In essence, attributes are a backdoor in Gramps. They give me the freedom to store items like the _UID exported by PAF, and the FSFTID exported by RootsMagic, which I use to exchange data with FamilySearch. And I get that freedom, because Gramps can store them, and will import and export them for me, but they are meaningless otherwise, meaning that the software does not try to interpret them.
Storing CSL variables in attributes means that you accept that they are meaningless, and that Gramps will not associate them with existing GEDCOM based variables. And although that’s technically OK, it does mean that you are creating a parallel world, and that’s the exact opposite of openness.
No it is you that don’t get the point, the variable names will be stored in the language that the user use, if there is a translation for that language for the CSL Style the user chose to use. The only place the variable names will be stored in English will be in the CSL JSON or BiblaTeX file that contain the metadata, the CSL Style itself will contain the languages that the Style is translated to.
(And as far as I have seen, every standard field/column name is stored in English in the database.)
Only customized attribute names are stored in the native language for the user, and that is no difference for the CSL with a tranlation.
If I use Norwegian as Interface language in Zotero or other software that support both the language and the Style, ALL my variable names and the CSL is in Norwegian, and the Style is formatted as it is supposed to in the local language.
Yes, if the user chose a Style that is not translated to his/her language, it will be imported in English…
But most countries use some kind of citation style as a default, and it is a huge chance that some university has translated that Style to native the official language as a minimum.
And if a Style is not translated or there is errors in it, a request can be sent to the CSL organization, or the user can do it him-/herself.
Before you write anything more, I do think you should start READ about CSL, CSL JSON, BiblaTeX etc.
And just to point out one other thing, the Zotero Forum post you linked to, that was a post about EE support ion Zotero, NOT about CSL!
DON’T create problems where there are no problems other than you own mind.
But this discussion has now gone over to just being waste of my time, because it is clearly that you have set your mind to not have interchangeable formats available neither for Gramps data nor the Citations metadata, and there is a lot of other things that I can do that is a lot better use of my time!
