Month field wrong when creating library compatible with bibtex and BibLaTeX

[foleyj2]

This is for JabRef 2.9.2 on linux but also relevant on the windows release.

I often work with reference libraries that must be used on both bibtex only journals in addition to biber/BibLaTeX. Until recently, I didn't have a problem with this under JabRef. (My students also noticed this problem.). The problem is how the Month field is formatted. If you put the month field to "March" or "mar", Jabref will always put {} around it.

This is a problem because biber/BibLaTeX can only deal with the short version without brackets. If you put "{mar}" it continues to skip the entries because it cannot convert them into the numeric representation. It has to be "Month = mar," or biber just returns an empty bibliography.
This has been mentioned in http://tex.stackexchange.com/questions/27898/biblatex-month-field

When BibLaTeX mode is enabled, you can't make a month field, only a date field, which is a problem for these older templates, which I don't have control over.
Please help. I don't want to have to edit the file manually to create the Month field.

[lenhard]

Hi @foleyj2,

JabRef 2.9.2 is quite outdated. Recently, there have been a few changes to field formatting that might have an impact on your problem. Can you please try out the current development version and check if your problem persists?

Also, do I understand you correctly that you expect the serialization to be like

Month = mar,

instead of

Month = {mar},

?

The first one will definitly not be supported by JabRef.

[mlep]

If you write

Month = {mar},

BibTeX understands that 'mar' is the string you want to be actually used for the month.

While

Month = mar,

is a BibTeX standard to abbreviate months (mar for March, apr for April, etc.). Depending on the bibliography style, it can be converted automatically to March (in English), Mars (in French), März (in German), etc.
As such, I believe both have to be supported. And in JabRef 2.10, both are.

BTW, the month abbreviation does not need to be defined by the user with an @string .

At this point, you may start hating BibTeX format... or find it beautiful! ;-)

[lenhard]

As far as I remember someone introduced some autocorrection functionality that automatically wraps non-wrapped fields in brackets. This might be a problem here, but I don't know.

I also believe that Bibtex should be supported in its standard fashion and I believe that people who want a certain feature (full Bibtex support) should be willing to implement it themselves and submit a pull request ;-)

P.S.: In other circumstances, we kind of already decided against full Bibtex support, see #214

[mlep]

Regarding #214 (i.e. using "" or {}), this is two ways of writing the same thing: this does not change the meaning for bibTeX, leading to the same compilation output. It is different here, about abbreviations.

More generally, when a user defines an abbreviation using a @string (in the preamble), the related field values will not be between brackets (or double quotes). Enforcing brackets everywhere means that user-defined abbreviations will not work anymore, right?

[koppor]

When I tried BibLaTeX, I think, it said that numbers should be used (month = {5}) instead of strings. That worked quite well for me.

[lenhard]

@mlep: Still, someone might complain that his favourite IDE, tool, whatever can only work with ". But anyways, you are right. At the moment, I am not at all sure how @string fields are actually written. And I am also not sure how the bracketing logic inside our write logic works. The code is simply just too weird. Still, this behavior is something we should keep in mind if we decide to re-write the serialization logic. Is there any similar field that I am not aware of or is it just month?

[simonharrer]

I only know about using #key#. For instance, IEEE journal abbreviations are defined in that way #journal_abbrev# in the official IEEE journal abbreviations.

[lenhard]

@simonharrer: Yes, with this knowledge in mind, the writing logic starts making a little more sense. I also found the following comment (but cannot guarantee that the code actually does this):

        // Here we assume that the user encloses any bibtex strings in #, e.g.:
        // #jan# - #feb#
        // ...which will be written to the file like this:
        // jan # { - } # feb

So it seems that

month = #jan#

should also work?

[matthiasgeiger]

So it seems that

month = #jan#

should also work?

Not exactly. In JabRef the content of the field "Month" must be #mar# which will then be serialized to:
Month = mar,
which is exactly what you would like to have @foleyj2, isn't it?

[oscargus]

Yes, the solution is indeed to write #may#etc. Cleanup Entries will replace jan/january/jan. etc with #jan# and so on if told to do so, with later versions being much more liberal in how to interpret the month.

[foleyj2]

I have not tried the #mon# method, but I tried the previously mentioned putting the number instead and that seems to have worked nicely. Thank you for all the help!

Joe

[matthiasgeiger]

Glad to hear!

[lenhard]

I added a test for the special syntax of the month field in eaf1b52

Everything is working fine, also with Month = mar,

@foleyj2 another solution would be to simply update JabRef.

[bluebirch]

Another option is to use the "date" field in biblatex, which allows values
like "2015-10" for year and months values only.

[foleyj2]

I would like to update it, but I don't want to use anything but standard packaged versions.
My students use MikTeX and I use TeXlive packaged in Fedora22.

Joe

[foleyj2]

I would use the date field except that I share my reference library among multiple templates, some of which must use bibtex (Journals) and others which use biber (internationalized internal reports)

Joe