I've suggested before that Zotero needs to add a user-friendly process for rich-text formatting so that, for example, parts of titles (like scientific names) can be shown in italics in the Zotero record as well as a bibliography that is produced from it. Since that is not yet possible, I was interested in how I might transfer records containing italicized words in titles from EndNote to Zotero. Here is what I did, which didn't work:

(1) I exported a set of records in RefMan (RIS) rich-text format to an rtf file.

(2) I opened that file in Word, then searched for italic formatting, then added the codes <i> and </i> before and after the italicized words (scientific names in this case).

(3) I saved this as a plain text file.

(4) When I open this in a plain text editor (I use EditPad Pro), I see the appropriate text with the <i> and </i> codes in the proper places, e.g.,

TI - Influences of predation risk and energy maximization on food selection by beavers (<i> Castor </i> <i> canadensis </i>)

(5) When I import this plain text file into Zotero 3.01, the records are imported correctly EXCEPT that the <i> and </i> codes are stripped off!

This would seem to be a bug in Zotero.

Thanks for your advice,

Steve Jenkins

This is clearly an explicit decision built into the RIS importer, and I can change it pretty easily. Are there any thoughts either way from others who use RIS?

If we lift this restriction, we'll probably still limit it to titles and abstracts, and only a small set of tags (italic, superscript, subscript, bold, underline)

Thanks for these comments, though I'm not sure I understand what constitutes a "hack" as opposed to a programming change that improves usability.

Another solution to my original problem of importing large numbers of references containing italicized scientific names in titles from EndNote into Zotero would be to modify step 2 of my original posting to use codes to identify the beginning and end of an italicized block of text that are not html codes, so presumably wouldn't be removed by Zotero. E.g., I might use $$ at the beginning and $$$ at the end. Then, if Zotero had a global search-and-replace feature, I could use this to change $$ to <i> and $$$ to </i> in the Zotero database. Or, I suppose this could be done directly in sqlite. But this is all not very user-friendly. The best solution of all would seem to be enabling Zotero to import rich-text files in RIS format that can be exported by EndNote.

I'll add my interest in having some solution to this problem. This is the final hurdle impeding my switch to Zotero from Reference Manager (2000+ records, with more 10% containing italics in the titles). My preference would be for the RIS importer to not strip the html codes, because that seems far easier (and quicker) to implement than building a global search and replace.

RM11, but that is immaterial - I massaged the RIS file to make it follow zotero's own system. The problem is exactly as described by shjenkins above. Everything imports correctly *except* the italics, despite my placing <i> and </i> before and after the italicized words by doing a search and replace on the hex (?) characters RM exports as the start/end tags for italics.

For example, the RIS text file with this:

T1 - Intrasexual aggression in <i>Metridium senile</i>

becomes this in Zotero after import:

Intrasexual aggression in Metridium senile

So, the problem is that Zotero does not import its own method for indicating italics in titles.

It's easy enough to put up a version of the RIS translator:
https://gist.github.com/raw/2335856/e28ca7fd32e70d0ddfa51740bb313b8b7df62cd9/RIS.js

Save this file (right-click --> save link as) to the translator folder in your Zotero data directory http://www.zotero.org/support/zotero_data
, overwriting the file with the same name.
Imports should work w/o html escaping immediately - if not, restart Firefox/Zotero and try again. The altered translator will get overwritten with future updates of Zotero so this is for a one-time import, but that sounds like it's all you need.
How to properly implement a permanent solution requires more thought, but I'm happy if this helps people to transfer their libraries.