Manual entry/editing - error checking too strict?

[glorious1]

ABT Version: 4.13.2

PHP Version: 7 something

Theme:

Plugin List:

• Plugin 1
• Plugin 2

Browser: Google Chrome (Version: xxx)

**Expected behavior:**Can edit/enter more or less freely.

**Actual behavior:**For authors, sometimes there is no author, or it may be Anonymous, or an institutional name. If I open such a reference to change something, I can't save without messing up the author field. I would suggest disabling all error checking on these name fields.

For page numbers, some online journals start their "page number" with an "e". Some print journals have page numbers that start with S for special issues. If I import a reference like that, it works fine, but I can't edit without deleting the letter.

Similarly, I have some references that have something like Pt. 7 in the issue field. It renders fine like that, but I can't edit the reference because of the error checking.

There may be other fields, but these are the ones that I bump into routinely.

Console messages:

// Paste messages here

[dsifford]

Good points. Let me consider this some more and make the adjustments when I get some free time.

[mjluser1]

I also have similar issues with the Author name field. Often I have names like "NIST" or "Nautical Almanac Office". Another one is "Wikipedia contributors", which how Wikipedia request we cite its pages.

[dsifford]

Author fields have the ability to toggle between human names and literal names already so you shouldn't have a problem there

[mjluser1]

Then I have not been able to figure it out so that the input displays correctly. Please explain what you mean and how to do it. Thank you.

…

------------ How many things, too, are looked upon as quite impossible until they have actually been effected? Pliny the Elder, Book VII, sec. 6

On Jan 23, 2018 9:39 AM, "Derek Sifford" ***@***.***> wrote: Author fields have the ability to toggle between human names and literal names already so you shouldn't have a problem there — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#422 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AhJzrSRdYtC-wGNk8r50kznzETtdpbX-ks5tNe7WgaJpZM4RlKec> .

[dsifford]

Next to the author remove button there is a button with the outline of a person on it. Click that to toggle between the two modes.

[glorious1]

Oh, I never noticed that was a toggle! Great!

[mjluser1]

Just discovered it will not accept Roman numerals as the page numbers for the Preface of a book. The error checking is nice, but can you give us the ability to override it? Or perhaps take the page numbers as whatever text we enter? Thanks.

[dsifford]

I'll look into further scrutinizing the validation when I get some more time.

Thanks for your patience

[mjluser1]

Discovered I can use Roman numerals for page numbers if I import and never have to manually edit the reference. If I try to manually edit it, it will not confirm without Arabic page numerals in the field.
Also discovered that when I export directly ris from JabRef and then directly into ABT, even for books it puts in SP and EP as empty page numbers. (I get "(p. )" in the reference.)

[dsifford]

@mjluser1 Can you share the RIS file that causes the error of empty page numbers?

Re: Non-arabic numerals -- I'll look into it soon.

[mjluser1]

For some reason when I exported the entire database the file from Jabref contained these lines for any item that did not have page numbers:
SP - --
EP -
ABT imported worked fine went I went in and removed them. I tried sharing it, but github does not accept .ris files. Those two lines were the only issue, and before and after that time my exports from JabRef does not contain them. So it appears it may be a non-issue.

I now have an EASY way to get references into ABT from JabRef while I am writing a blog post.

1. Select the entry or entries in JabRef (use Control key to select multiple entries)
2. Click on a selected entry with right mouse button and select Export to clipboard from dropdown menu.
3. Left button to select RIS and then click OK.
4. Paste from clipboard into an empty Notepad++ file
5. Use Edit > EOL conversions > Unix (LF) to remove all CR's
6. Use replace to change A2 to ED and save file
7. Use ABT import references to add contents of the file to uncited references
8. Delete file contents and save empty file for next use

This has repeatedly worked perfectly for me!

[dsifford]

@mjluser1 That sounds like a nightmare. Sorry you're forced to do that.

This is going to be exclusively a JabRef issue. I'd recommend opening an issue there. It should be fairly simple to fix on their end.

cc: @koppor @lenhard

[mjluser1]

The only issues I see are removing the CRs and changing the line code for editor. This is for pulling one (or a few) references as a time when they are first used. Otherwise I just exported to a file, do the two cleanups, and then import it. The process sounds a lot worse than it is---it takes less than a minute to do (esp. as I am working with three monitors so all three files are visible). Maybe I am missing something, but now I am happy with ABT for import and export.

[dsifford]

@mjluser1 carriage returns should work just fine now on the ABT side.

The issue I'm referring to is the empty SP and EP fields that are transferred to the RIS file. Those should not exist.

Once that small change happens on the JabRef side, you should be able to import without changing anything in a text editor.

[dsifford]

The main portion of this issue has been fixed in 4.13.3.

Because of that, I'm marking this as closed.

[lenhard]

@mjluser1 The problems with the A2/ED fields should be fixed in the most recent (and yet unreleased) development version available here: http://builds.jabref.org/master/

Regarding line endings: We just default to the operating system and if your JabRef runs on Windows, line endings will include CRs. On Linux it should just be a \n.

Regarding the SP/EP fields: It is probably best if you open an issue at https://github.com/JabRef/jabref/issues and give us the full bibTeX code of an entry, along with the expected RIS output. If we have this information, it should be no problem to fix the export functionality.