Please check out my latest guest article on the JewishGen Blog:
JewishGen Basics: JewishGen Online Worldwide Burial Registry (JOWBR)
In the article I cover how to use JOWBR to find graves all over the world (there are over 1.5 million records in JOWBR), as well as other Jewish cemetery resources including JewishData.com, CemeteryScribes.com, MountOfOlives.co.il, DeathIndexes.com and many more.
Wednesday, June 29, 2011
Monday, June 27, 2011
Another look at GRAMPS
Back in January I took a look at the free genealogy program GRAMPS. GRAMPS started on Linux, but is now available for Windows and Mac. I was looking at it specifically for use on the Mac, as that's the platform I use. At the time, at version 3.2.5, it was not yet stable enough on the Mac to use. Indeed there was at least one major issue which I submitted as a bug to the developers, but I haven't had time since then to fully test it again. Recently version 3.3.0 was released, and I decided to give it a spin once again. As I mentioned back in January, I really like the idea of a free open-source cross-platform genealogy program, and I'm rooting for GRAMPS to be competitive with other genealogy programs out on the market.
This time, things went a lot smoother than my first attempt. For one, everything installed easily and I didn't see any error messages when loading the program. Oddly the program loaded on my second monitor, which is very unusual. It's possible I had moved the application to my second monitor back in January and this version accessed some preference file from the old version, but in any case I've never seen an app boot directly to my second monitor.
Exporting and Correcting a GEDCOM from Reunion
The first thing I did was export a GEDCOM file from Reunion to load into GRAMPS. Knowing from previous attempts that GRAMPS would not recognize the relative paths used int the image file locations, I opened the GEDCOM first in a text editor and did a find-and-replace on the relative path:
In the above image (click to enlarge) you can see the relative path on the line that starts with FILE starts with ~/ which is supposed to point to my home directory. This is a UNIX shortcut, which makes it is surprising that GRAMPS doesn't know how to deal with it. In any event, on the Mac your home directory is located at /Users/USERNAME/ or in my case /Users/philip/ and as you can see in the Find box, I replace all instances of ~/ with /Users/philip/.
In the above image you can see that 935 instances of ~/ were replaced, including in the image location shown in the GEDCOM.
One other thing to notice in the GEDCOM is that Reunion output not only the image location, but a line called _CROP which gives coordinates of how the image was cropped within Reunion. Reunion lets you re-use images with different people (or even multiple times with the same person) and for each instance of the image you can crop it how you'd like. For example, if you have a family photo that shows two parents and four children, you can assign that photo to all six people, and crop the photo for each person so when displayed will only show the head of the person you want. This is a very nice feature, but GEDCOM doesn't have a standard way to deal with it. I don't even know if GRAMPS can handle per-instance cropping of photos, but in any case it certainly doesn't know how to import Reunion's cropping information. Hopefully the efforts to improve/replace GEDCOM will in the future include a standard way to share that kind of information, and hopefully GRAMPS will add this feature as well.
Importing the GEDCOM into GRAMPS
Once I made the replacements in the file I wanted to load it into GRAMPS. For those used to standard Mac user-interface norms, GRAMPS doesn't try to match them. This has been a complaint by other users of GRAMPS, that they should try to adapt to the user-interface 'widgets' of the operating systems they are targeting. Beyond the look of an app, there are also usage norms of which Linux users, Mac users and Windows users all expect something different. That said, I'm not sure if some of the user-interface issues are due to the fact that the program originated on Linux, or are just the user-interface decisions of the developers. When getting started, GRAMPS makes you create a new family tree, then load the new tree (which oddly takes more than a few seconds) and then lets you import a GEDCOM. The GEDCOM import was quite fast, and in my case importing 1800 records took only few moments. Why couldn't I just import a GEDCOM into a new family tree? No idea.
GRAMPS Views
GRAMPS offers several very interesting views of your data - People, Relationships, Families, and Ancestry. GRAMPS also lets you look at your Events, Places, Geography, Sources, Media and Notes. These views are great, as they let you look at your data in some very useful ways very quickly. One thing that is very interesting, for example, is to be able to see all the Places that are present in your family tree. As Reunion does not standardize place names, in my case the list of Places shows some of the many duplicate and inconsistent names I've used in my tree. It also lets you easily correct the names and then merge duplicate names so that they link to a single reference. Thus, if you choose to change the name of the town later, the change will show up in all records that reference that location.
I also tried the Geography view which starts out as a map of the world, but somehow I zoomed out so far that I couldn't see anything and I couldn't get it to go back to a normal view of the Map. In fact, the coordinates shown for my location on the map was:
Now I wasn't a geography major, but I'm pretty sure it's not possible to go to W 16534˚ on a map. Now the way I zoomed was using the multi-touch trackpad on my MacBook Pro, which the developers who use Linux might not be familiar with, so perhaps this bug isn't possible to reproduce on Linux, but it definitely exists on the Mac. A map reset button might be good here.
In any event, I like that with each view there is a Filter panel that lets you search within the view and reduce the number of records shown to match what you're searching. Reunion lets you search lots of fields, probably more than GRAMPS, but it does so from a single search window, and you either search one field or all fields at once. GRAMPS' filtering seems more useful for quick searches within the view you're currently in.
I have to say, having used Reunion for more than ten years, the views in GRAMPS seem a bit strange to me. Obviously one can argue over what views are best in genealogy program, and having many options (Reunion is really just one view) is a good thing, but I find the views somewhat redundant and inconsistent. For example, The Relationships view is a view that shows all the direct relationships of a person, such as parents, spouse(s), children and siblings. The siblings are a nice touch since most genealogy programs only show parents and children of a person in a single view. That said, I generally need to scroll down to see all the information in this view, which limits its usefulness for quick navigation through family members. In Reunion, which is based on a Family view (a Couple is the center of the view, which shows basic information on each of the couple's parents above them, and of all of their children below them), if I want to see someone's siblings I click on the parents of the person, and the parents become the couple at the center of view, and the children at the bottom include the person I was originally looking at and all of his/her siblings. That isn't necessarily the most natural way to see this information, but it works in a very consistent manner. Thus it is easy for me to navigate up and down through the tree using just this single Family view.
In GRAMPS, the closest thing to the view in Reunion is the Families view, except that its usage is user-interface-challenged. For example, if I go to the Families view I see a list of families, which is essentially a list of couples and their marriage dates if known. If I click on a couple I get a view that is similar to Reunion's view that pops up in a new window (except it only shows parents and children, not the parents of the couple). In this new window, if I click on the one of the parents' names, for example, nothing happens. There is a little document icon next to the names, however, and if I click on that icon I get a third window which lets me edit the person's details (this is actually the same as Reunion except Reunion doesn't use an icon but lets you just click on the name). Indeed this is the People view in GRAMPS, so you are seeing more than one view at a time). If I click on the childrens' names, I get a different window which just seems to allow me to define the relationship of the child to the parent (birth, adopted, etc.). This seems like a waste of a window. If I was going to have a window like this, I would at least allow you to switch who the parents are of the child (such as when there are multiple marriages and you find that a child was born from a different set of parents than you thought). This raises a few other UI decisions I don't understand in GRAMPS. In the view showing the parents and children, there is a minus sign that lets you remove one of the parents as a parent - but of which child? What if the father is the father of one child but not the other? In addition, there seems no logical way to add additional spouses in this view. Second marriages are common enough that this should be integrated into the view.
No Easy Navigation
The worst part of the UI seems to be that there is no way to easily navigate to other families through the view itself. Instead, I need to close the window, go back to the list of families and find the right family. That's a bit absurd actually, especially if you have lots of people with similar names in your tree, or if you simply don't remember the names of the parents. Reunion is a bit limited in its single view, but it is actually very easy to navigate within that view to find almost all the information you need quickly.
You might have noticed that earlier I said above that the user-interface in GRAMPS is inconsistent. Let me give an example. In the above mentioned view you can't easy switch to the parents or children. In the Ancestry view, which is a kind of navigatable graphic tree, you can click on a parent of the person at the 'bottom' of the tree (it's actually on the left side) to make them the bottom of the tree, but if the tree doesn't show the children of the bottom person. There is a pop-up menu you can click on and then choose a child in order to make them the bottom person. This seems a weak UI choice. Why not show all the children of the primary person in the tree, to allow quick navigation of the entire tree. My main problem with GRAMPS is navigation-oriented, and when I see different (inconsistent) choices made in different views, and no easy way to navigate in a single window to information on different families, it is a big problem for me.
In the End...
After writing the above I decided to check out the different graphical views and reporting options, but ran into a roadblock. When trying to switch to a different Ancestry view (Timeline Pedigree) an error message was generated, and I was unable to continue. Indeed, this issue has prevented me from adding many of the screenshots I intended to add to the above to illustrate various features. I was prompted to submit a bug report which I did, but when I tried to re-launch GRAMPS and re-load my family tree I kep getting an error message saying the database was corrupt and to run a tool to fix it, but the program would crash before I could access the tool to fix the database. I suppose I could delete the tree and start over, but for the time being I'm going to wait. While this version (3.3.0) is much more stable than the previous version I tested, it clearly is not ready yet for everyday use, at least not on a Mac. I look forward to testing it in the future when these issues have been worked out.
This time, things went a lot smoother than my first attempt. For one, everything installed easily and I didn't see any error messages when loading the program. Oddly the program loaded on my second monitor, which is very unusual. It's possible I had moved the application to my second monitor back in January and this version accessed some preference file from the old version, but in any case I've never seen an app boot directly to my second monitor.
Exporting and Correcting a GEDCOM from Reunion
The first thing I did was export a GEDCOM file from Reunion to load into GRAMPS. Knowing from previous attempts that GRAMPS would not recognize the relative paths used int the image file locations, I opened the GEDCOM first in a text editor and did a find-and-replace on the relative path:
 |
| GEDCOM excerpt showing relative path to an image file |
 |
| GEDCOM excerpt showing absolute path to an image file (after Replace All) |
One other thing to notice in the GEDCOM is that Reunion output not only the image location, but a line called _CROP which gives coordinates of how the image was cropped within Reunion. Reunion lets you re-use images with different people (or even multiple times with the same person) and for each instance of the image you can crop it how you'd like. For example, if you have a family photo that shows two parents and four children, you can assign that photo to all six people, and crop the photo for each person so when displayed will only show the head of the person you want. This is a very nice feature, but GEDCOM doesn't have a standard way to deal with it. I don't even know if GRAMPS can handle per-instance cropping of photos, but in any case it certainly doesn't know how to import Reunion's cropping information. Hopefully the efforts to improve/replace GEDCOM will in the future include a standard way to share that kind of information, and hopefully GRAMPS will add this feature as well.
Importing the GEDCOM into GRAMPS
Once I made the replacements in the file I wanted to load it into GRAMPS. For those used to standard Mac user-interface norms, GRAMPS doesn't try to match them. This has been a complaint by other users of GRAMPS, that they should try to adapt to the user-interface 'widgets' of the operating systems they are targeting. Beyond the look of an app, there are also usage norms of which Linux users, Mac users and Windows users all expect something different. That said, I'm not sure if some of the user-interface issues are due to the fact that the program originated on Linux, or are just the user-interface decisions of the developers. When getting started, GRAMPS makes you create a new family tree, then load the new tree (which oddly takes more than a few seconds) and then lets you import a GEDCOM. The GEDCOM import was quite fast, and in my case importing 1800 records took only few moments. Why couldn't I just import a GEDCOM into a new family tree? No idea.
GRAMPS Views
GRAMPS offers several very interesting views of your data - People, Relationships, Families, and Ancestry. GRAMPS also lets you look at your Events, Places, Geography, Sources, Media and Notes. These views are great, as they let you look at your data in some very useful ways very quickly. One thing that is very interesting, for example, is to be able to see all the Places that are present in your family tree. As Reunion does not standardize place names, in my case the list of Places shows some of the many duplicate and inconsistent names I've used in my tree. It also lets you easily correct the names and then merge duplicate names so that they link to a single reference. Thus, if you choose to change the name of the town later, the change will show up in all records that reference that location.
I also tried the Geography view which starts out as a map of the world, but somehow I zoomed out so far that I couldn't see anything and I couldn't get it to go back to a normal view of the Map. In fact, the coordinates shown for my location on the map was:
 | |
| Geography view coordinates |
In any event, I like that with each view there is a Filter panel that lets you search within the view and reduce the number of records shown to match what you're searching. Reunion lets you search lots of fields, probably more than GRAMPS, but it does so from a single search window, and you either search one field or all fields at once. GRAMPS' filtering seems more useful for quick searches within the view you're currently in.
I have to say, having used Reunion for more than ten years, the views in GRAMPS seem a bit strange to me. Obviously one can argue over what views are best in genealogy program, and having many options (Reunion is really just one view) is a good thing, but I find the views somewhat redundant and inconsistent. For example, The Relationships view is a view that shows all the direct relationships of a person, such as parents, spouse(s), children and siblings. The siblings are a nice touch since most genealogy programs only show parents and children of a person in a single view. That said, I generally need to scroll down to see all the information in this view, which limits its usefulness for quick navigation through family members. In Reunion, which is based on a Family view (a Couple is the center of the view, which shows basic information on each of the couple's parents above them, and of all of their children below them), if I want to see someone's siblings I click on the parents of the person, and the parents become the couple at the center of view, and the children at the bottom include the person I was originally looking at and all of his/her siblings. That isn't necessarily the most natural way to see this information, but it works in a very consistent manner. Thus it is easy for me to navigate up and down through the tree using just this single Family view.
In GRAMPS, the closest thing to the view in Reunion is the Families view, except that its usage is user-interface-challenged. For example, if I go to the Families view I see a list of families, which is essentially a list of couples and their marriage dates if known. If I click on a couple I get a view that is similar to Reunion's view that pops up in a new window (except it only shows parents and children, not the parents of the couple). In this new window, if I click on the one of the parents' names, for example, nothing happens. There is a little document icon next to the names, however, and if I click on that icon I get a third window which lets me edit the person's details (this is actually the same as Reunion except Reunion doesn't use an icon but lets you just click on the name). Indeed this is the People view in GRAMPS, so you are seeing more than one view at a time). If I click on the childrens' names, I get a different window which just seems to allow me to define the relationship of the child to the parent (birth, adopted, etc.). This seems like a waste of a window. If I was going to have a window like this, I would at least allow you to switch who the parents are of the child (such as when there are multiple marriages and you find that a child was born from a different set of parents than you thought). This raises a few other UI decisions I don't understand in GRAMPS. In the view showing the parents and children, there is a minus sign that lets you remove one of the parents as a parent - but of which child? What if the father is the father of one child but not the other? In addition, there seems no logical way to add additional spouses in this view. Second marriages are common enough that this should be integrated into the view.
No Easy Navigation
The worst part of the UI seems to be that there is no way to easily navigate to other families through the view itself. Instead, I need to close the window, go back to the list of families and find the right family. That's a bit absurd actually, especially if you have lots of people with similar names in your tree, or if you simply don't remember the names of the parents. Reunion is a bit limited in its single view, but it is actually very easy to navigate within that view to find almost all the information you need quickly.
You might have noticed that earlier I said above that the user-interface in GRAMPS is inconsistent. Let me give an example. In the above mentioned view you can't easy switch to the parents or children. In the Ancestry view, which is a kind of navigatable graphic tree, you can click on a parent of the person at the 'bottom' of the tree (it's actually on the left side) to make them the bottom of the tree, but if the tree doesn't show the children of the bottom person. There is a pop-up menu you can click on and then choose a child in order to make them the bottom person. This seems a weak UI choice. Why not show all the children of the primary person in the tree, to allow quick navigation of the entire tree. My main problem with GRAMPS is navigation-oriented, and when I see different (inconsistent) choices made in different views, and no easy way to navigate in a single window to information on different families, it is a big problem for me.
In the End...
After writing the above I decided to check out the different graphical views and reporting options, but ran into a roadblock. When trying to switch to a different Ancestry view (Timeline Pedigree) an error message was generated, and I was unable to continue. Indeed, this issue has prevented me from adding many of the screenshots I intended to add to the above to illustrate various features. I was prompted to submit a bug report which I did, but when I tried to re-launch GRAMPS and re-load my family tree I kep getting an error message saying the database was corrupt and to run a tool to fix it, but the program would crash before I could access the tool to fix the database. I suppose I could delete the tree and start over, but for the time being I'm going to wait. While this version (3.3.0) is much more stable than the previous version I tested, it clearly is not ready yet for everyday use, at least not on a Mac. I look forward to testing it in the future when these issues have been worked out.
Friday, June 17, 2011
Variations in Jewish Given Names
I've written about Jewish given names before, but I wanted to look at a different aspect in this article. The main thing I'd like to point out is that given names change over time, and someone might be known as one name in one location and as something else after moving to another country, or even another town. Sometimes, for example, a name changed by an immigrant is easy to guess at, since the name has a clear equivalent in the new country. What happens when the equivalent is not considered a good name when the person arrives? Pinkhas is a Hebrew name which is fine in Hebrew, but the anglicized version is Phineas (not so popular). So what name might an immigrant have taken? Philip? Paul? It could be anything. However, that misses the point that sometimes we are staring at a name and have no idea what name it is actually. For example, I had a gg-grandfather whose first name was Shubsa. I didn't know what name that was, and in the US he went by Sam. Sam is short for Samuel, or in Hebrew Shmuel. Is Shubse some kind of Yiddish nickname for Shmuel? Actually, it's a Yiddish pronunciation of a variant of Shabbtai, a totally different name. There's a derivation there which can be discovered, but it's not the most obvious derivation to someone who doesn't know Yiddish and is unfamiliar with the name. Indeed, for my gg-grandfather there was no easy English equivalent (such as someone name Yitzkhok going by Isaac, or someone named Yishai going by Jesse), which is why he went by Sam.
I've created a chart below that takes a small sampling of names, and compares what they look like in Hebrew, Yiddish, Polish and of course English. For English, I've given two versions which are the Anglicized version (i.e. the version likely to appear in an English-language bible and to be used by people in English-speaking countries today) and the transliterated version of the original Hebrew name (used by some religious Jewish people even today instead of the Anglicized version, but is mainly there to illustrate the difference between the Anglicized version and the original).
In the case of Yiddish and Polish names, there are many other possibly variations for many of the names listed. I've tried to list either the most commonly used and the most clearly different names (i.e. ones you would be unlikely to track backward to the original without help). Don't hold me to being consistent with my transliteration of the Yiddish and Polish names. My goal was to make them readable, not consistent.
A few more notes. I use the letter-pair kh to represent the Hebrew letter Khet (ח). In English the more common pairing to use for spelling is actually ch, such as in Chanukah, although for the same reason Chanukah is frequently spelled Hanukah instead (because in English we reserve the ch pairing for a totally different sound, such as in the word 'chair') I use the pairing kh which is distinct from h, but cannot be confused with the sound we normally use for ch. This is why I write 'Rakhael' for the Hebrew transliteration of Rachel, but put 'Rachel' in parenthesis since in fact most women who bear this name write it as 'Rachel' even if they pronounce it as 'Rakhael'. In fact, I've seen some people write their name as Rachael, which is a mix of those approaches (yet something which doesn't help people to pronounce the name correctly).
As an aside, I wanted to point out a street sign I noticed the other day while walking in Jerusalem:
If one were to transliterate the Hebrew name properly, it would be Shimon St. In English, however, the name was anglicized into Simeon, or Simon. Somehow the person determining the proper name in English combined the proper transliteration (including the Sh sound instead of S) but also included the anglicized contribution of -eon from Simeon, even though that sound doesn't exist in the original Hebrew. It was actually this sign which put the idea in my head to write this article.
I give the city a hard time, and indeed the mis-named streets are a long-running joke among native English-speakers in Israel (as are mis-spelled and mis-translated restaurant menus), but they have gotten better over the years. I once noticed a street that had three different English spellings on three different street signs for the street, including two different spellings on different sides of the same sign. They later changed them to all be the same.
My favorite street in Jerusalem is Abraham Lincoln St., where in Hebrew they pronounce the silent l, and get something like Avraham Linko-lin. Try to pronounce that name with the correct English pronunciation to a taxi driver, and you won't get anywhere. Pronounce it Linko-lin and you're golden.
I should add that these examples (besides being amusing) are intended to help you realize that just like government bureaucrats in these cases didn't bother to spend the time to find the correct spelling or pronunciation of a name, when one's ancestors were traveling through Europe, getting on ships, arriving in the US, similar bureaucrats may also have not spelled things correctly. Also, while we are pretty strict with spelling these days, it was not a sacrosanct a hundred years ago.
For more information on Jewish given names, there are some very good books and web sites available. Here are a few books:
Beider, Alexander. A Dictionary of Ashkenazic Given Names: Their Origins, Structure, Pronunciation, and Migrations. Bergenfield, NJ: Avotaynu, 2001. 728pgs
Hoffman, William F., and George W. Helon. First Names of the Polish Commonwealth: Origins & Meanings. Chicago: Polish Genealogical Society of America, 1998. 426pgs
Gorr, Shmuel, and Chaim Freedman. Jewish Personal Names: Their Origin, Derivation, and Diminutive Forms. Teaneck, NJ: Avotaynu, 1992. 128pgs
Feldblyum, Boris. Russian Jewish Given Names. Teaneck, NJ: Avotaynu, 1998. 152pgs
Cohn, Rella Israly. Yiddish Given Names: a Lexicon. Lanham, MD: Scarecrow, 2008. 432pgs
A few notes on the books:
Beider's Dictionary (and its less expensive Handbook version) is really an amazing resource, but keep in mind when using it that it does not attempt to bring any modern context to the names. For all intents and purposes it ends its look at the names mentioned around 150 years ago. This is not a criticism, just an acknowledgement that the book does not try to look at the evolution of the names into the 20th century. It is still incredibly useful, but you will not find any information in the book about modern usage or changes in the names.
Hoffman and Helon's book on Polish names is a great book and a bargain. It is a publication of the Polish Genealogical Society of America, and is not specifically Jewish, but it has broad coverage of Jewish names, and shows the Jewish roots of many Polish names. It points out the different pronunciations and spellings of names that came from different regions, and when there is a specific Jewish version it generally points it out.
Gorr's book, which was finished after his death by Freedman, is certainly not as scientific a look at the history of given names as Beider's, but it is nonetheless very important as a look at the actual usage of many of the names listed in this brief work. Unlike Beider whose name variations are shown using transliteration, Gorr's book shows the variations with the original Yiddish (in Hebrew lettering) and transliteration. Considering the difference in spelling between Hebrew and Yiddish, this is a very useful feature of the book. It's a short book, but with some great information.
Feldblyum's book on Russian names has the most interesting story behind the book. It is largely based on a Russian book published in 1911 by Iser Kulisher in Zhitomir, Ukraine. The book was intended to help government bureaucrats make sense of all the variations of Jewish given names. This was a serious problem, as people were forbidden to change their name as recorded at their birth. If they were listed in a document with even the slightest variation of their name, the listing was considered a different person. To use an example from the book, if a tax list showed that Moshe paid his taxes, but his name in another register was listed as Mojshe, then he could be taxed again.
Cohn's book on Yiddish names, like Gorr's, was also published posthumously. As an academically published book it is incredibly expensive (listed at $165). For that price, you get much less than the much larger, more comprehensive (and at $85 cheaper) Beider book (or even in some ways the $29 Handbook). The introductory essays of the book are good, but the lexicon itself is a bit frustrating. For example, for a book on Yiddish names, it doesn't actually include the original Yiddish spellings in the book at all, only transliterations. Truthfully, Beider doesn't include the names in their original Yiddish either, but at least he references the Hebrew names they are based on (in Hebrew) and provides an index of the Yiddish names in Hebrew letters in the back of the book. Cohn offers an index of Hebrew names as well, but oddly transliterates those too. Her index of English names and the Yiddish equivalents is useful. I wonder if some of these shortcomings would have been fixed if Cohn had lived to finish the book herself instead of having it finished after her death.
For web sites, one place to look is the Given Name Data Bases (GNDBs) at JewishGen. Truthfully, this database drives me nuts. It appears to have been last updated in 2003. You can search for 'European' names or 'Foreign Names' which means, for example you can search for names that were from Poland which is European and see what people changed their names to in the United States which is Foreign. In reverse, you can choose a Foreign country and see name changes to a European country. The records that you see are as varied as the people who filled out the information that makes up the database. Some records provide many alternate names, some don't. It would seem the database is in need of a major overhaul, and merging into a single database would be a nice start. Also, beyond this major limitation, it doesn't actually tell you the origin of the names, but only what the person who filled out their individual information filled out. The information therefore can be very useful for trying to figure out what someone named Berish who lived in Romania and moved to Argentina might have changed their name to (Bernardo) but it's more hit-or-miss when trying to just find out about the name Berish (you nee to pick European/Foreign pairs to search and hope you get lucky).
A general site on given names called Behind the Name, has a section on Jewish names which is very useful. The site shows the etymology and history of names, and will show the language of original (Hebrew or Yiddish for example). If the name was originally in Hebrew or Yiddish, the site will also give you the name in Hebrew letters.
Another useful site, believe it or not, is Wikipedia. Obviously it's not consistent on how it deals with names, but there are many Wikipedia entries on given names. Try searching for a name and add 'given name' to the search. For example, see these entries for Israel (name) and Rebecca (given name).
What's your favorite name story? What name did it take years for you to decipher? Post your stories in the comments.
I've created a chart below that takes a small sampling of names, and compares what they look like in Hebrew, Yiddish, Polish and of course English. For English, I've given two versions which are the Anglicized version (i.e. the version likely to appear in an English-language bible and to be used by people in English-speaking countries today) and the transliterated version of the original Hebrew name (used by some religious Jewish people even today instead of the Anglicized version, but is mainly there to illustrate the difference between the Anglicized version and the original).
In the case of Yiddish and Polish names, there are many other possibly variations for many of the names listed. I've tried to list either the most commonly used and the most clearly different names (i.e. ones you would be unlikely to track backward to the original without help). Don't hold me to being consistent with my transliteration of the Yiddish and Polish names. My goal was to make them readable, not consistent.
A few more notes. I use the letter-pair kh to represent the Hebrew letter Khet (ח). In English the more common pairing to use for spelling is actually ch, such as in Chanukah, although for the same reason Chanukah is frequently spelled Hanukah instead (because in English we reserve the ch pairing for a totally different sound, such as in the word 'chair') I use the pairing kh which is distinct from h, but cannot be confused with the sound we normally use for ch. This is why I write 'Rakhael' for the Hebrew transliteration of Rachel, but put 'Rachel' in parenthesis since in fact most women who bear this name write it as 'Rachel' even if they pronounce it as 'Rakhael'. In fact, I've seen some people write their name as Rachael, which is a mix of those approaches (yet something which doesn't help people to pronounce the name correctly).
| Anglicized Name | Transliterated Hebrew | Transliterated Yiddish | Polish Name(s) | Hebrew | Gn |
| Aaron | Aharon (Aron) | Arn/Oren | Aron | אַהֲרֹן | M |
| Abigael | Avigayil | Avigayl | Abigail | אֲבִיגַיִל | F |
| Abraham | Avraham | Avrom/Avrum | Abram | אַבְרָהָם | M |
| Alexander | Alexander | Sander/Sender | Szandor | אַלֶכְּסַנְדְר | M |
| Anna/Hannah | Chana | Khane/Knanke | Hanka/Hania | חַנָּה | F |
| Daniel | Daniyel | Danil/Donye | Danilo/Danek | דָּנִיֵּאל | M |
| Deborah | Devora | Devorye/Dvoshe | Dworja | דְּבוֹרָה | F |
| Ephraim | Ephraim | Efroyim/Froyke | Efrem/Akram | אֶפְרָיִם | M |
| Eliezer | Eliezer | Elieyzer/Leyzer | Lejzor | אֱלִיעֶזֶר | M |
| Elizabeth | Elisheva | Elisheve | Elzbieta/Elka | אֱלִישֶׁבַע | F |
| Eve | Chava | Khave | Chawa/Ewa/Ewka | חַוָּה | F |
| Gabriel | Gavriel | Gavriel/Gavrilik | Gabor/Gabrys | גַבְרִיאֵל | M |
| Isaiah | Yehoshua | Ishaye/Shaye | Izajasz | יְשַׁעְיָהוּ | M |
| Isaac | Yitzchak | Ayzik/Itskhok/Izak/Itzik | Izaak/Icchok/Icek | יִצְחָק | M |
| Israel | Yisroel | Isroel/Srulik | Izrael/Iser/Srul | יִשְׂרָאֵל | M |
| Jacob | Yakov | Yankef/Yankel | Jakub/Jankiel/Kuba | יַעֲקֹב | M |
| Jeremiah/Jeremy | Yirmiyahu | Yirmiya/Irmye | Jeremiasz | יִרְמְיָהוּ | M |
| Joel | Yo'el | Yoyel | Joil/Jowel | יוֹאֵל | M |
| Jonah | Yonah | Yona/Yoyne/Yavne | Jonasz | יוֹנָה | M |
| Jonathan | Yonatan | Yehoynosn | Jonatan | יוֹנָתָן | M |
| Joseph | Yoseph | Yoysef/Yose/Yosl | Jozef/Josel | יוֹסֵף | M |
| Joshua | Yehoshua | Yehoshue/Yoshue/Hesyl | Jozue/Gowsiej/Hojsza/Szyja | יְהוֹשֻׁעַ | M |
| Judah | Yehuda | Yehude | Juda/Judka/Idel | יְהוּדָה | M |
| Leah | Leah | Leye/Laya | Leja/Lejka | לֵאָה | F |
| Matthew | Mattityahu | Mates | Maciej/Maciek/Mateusz | מַתִּתְיָהוּ | M |
| Michael | Mikha'el (Michael) | Mikhoel/Mikhke | Michal/Michalek/Michas | מִיכָאֵל | M |
| Moses | Moshe | Moyshe | Mojzesz/Mosko/Moszka | מֹשֶׁה | M |
| Nathaniel | Natan'el | Nisanel/Sanel/Sanyek | Natanael/Sanel | נְתַנְאֵל | M |
| Obadiah | Ovadiah | Ovadye/Vadye | Abdiasz | עֹבַדְיָה | M |
| Rachel | Rakhael (Rachel) | Rokhl/Rokhe | Rachela/Ruchla/Rechel | רָחֵל | F |
| Rebecca | Rivka | Rifke/Rive | Rywka/Rebeka/Rysza | רִבְקָה | F |
| Reuben | Reuven | Ruven/Ruvn/Rubin | Ruben | רְאוּבֵן | M |
| Samson | Shimshon | Shimshen/Shimshl | Szymszon/Samson/Szymszel | שִׁמְשׁוֹן | M |
| Samuel | Shmuel | Shmuel/Shmul/ | Szmul/Sam/Samek | שְׁמוּאֵל | M |
| Sarah | Sara | Sore/Sorke/Tserl | Sara/Sura/Cyra | שָׂרָה | F |
| Saul | Shaul | Shoyel/Shaul | Saul/Szoel/Szawel/Zavel | שָׁאוּל | M |
| Simon | Shimon | Shimen | Szymon/Szymen/Zymel | שִׁמְעוֹן | M |
| Solomon | Shlomo | Shloyme/Zalman | Salomon/Szloma/Zalman | שְׁלֹמֹה | M |
| Susanna | Shoshana | Shoshane/Shoshe | Szoszana/Zuzanna/Szosa | שׁוֹשַׁנָּה | F |
As an aside, I wanted to point out a street sign I noticed the other day while walking in Jerusalem:
 |
| Shimeon St. in Jerusalem, Israel |
I give the city a hard time, and indeed the mis-named streets are a long-running joke among native English-speakers in Israel (as are mis-spelled and mis-translated restaurant menus), but they have gotten better over the years. I once noticed a street that had three different English spellings on three different street signs for the street, including two different spellings on different sides of the same sign. They later changed them to all be the same.
My favorite street in Jerusalem is Abraham Lincoln St., where in Hebrew they pronounce the silent l, and get something like Avraham Linko-lin. Try to pronounce that name with the correct English pronunciation to a taxi driver, and you won't get anywhere. Pronounce it Linko-lin and you're golden.
I should add that these examples (besides being amusing) are intended to help you realize that just like government bureaucrats in these cases didn't bother to spend the time to find the correct spelling or pronunciation of a name, when one's ancestors were traveling through Europe, getting on ships, arriving in the US, similar bureaucrats may also have not spelled things correctly. Also, while we are pretty strict with spelling these days, it was not a sacrosanct a hundred years ago.
For more information on Jewish given names, there are some very good books and web sites available. Here are a few books:
Beider, Alexander. A Dictionary of Ashkenazic Given Names: Their Origins, Structure, Pronunciation, and Migrations. Bergenfield, NJ: Avotaynu, 2001. 728pgs
Hoffman, William F., and George W. Helon. First Names of the Polish Commonwealth: Origins & Meanings. Chicago: Polish Genealogical Society of America, 1998. 426pgs
Gorr, Shmuel, and Chaim Freedman. Jewish Personal Names: Their Origin, Derivation, and Diminutive Forms. Teaneck, NJ: Avotaynu, 1992. 128pgs
Feldblyum, Boris. Russian Jewish Given Names. Teaneck, NJ: Avotaynu, 1998. 152pgs
Cohn, Rella Israly. Yiddish Given Names: a Lexicon. Lanham, MD: Scarecrow, 2008. 432pgs
A few notes on the books:
Beider's Dictionary (and its less expensive Handbook version) is really an amazing resource, but keep in mind when using it that it does not attempt to bring any modern context to the names. For all intents and purposes it ends its look at the names mentioned around 150 years ago. This is not a criticism, just an acknowledgement that the book does not try to look at the evolution of the names into the 20th century. It is still incredibly useful, but you will not find any information in the book about modern usage or changes in the names.
Hoffman and Helon's book on Polish names is a great book and a bargain. It is a publication of the Polish Genealogical Society of America, and is not specifically Jewish, but it has broad coverage of Jewish names, and shows the Jewish roots of many Polish names. It points out the different pronunciations and spellings of names that came from different regions, and when there is a specific Jewish version it generally points it out.
Gorr's book, which was finished after his death by Freedman, is certainly not as scientific a look at the history of given names as Beider's, but it is nonetheless very important as a look at the actual usage of many of the names listed in this brief work. Unlike Beider whose name variations are shown using transliteration, Gorr's book shows the variations with the original Yiddish (in Hebrew lettering) and transliteration. Considering the difference in spelling between Hebrew and Yiddish, this is a very useful feature of the book. It's a short book, but with some great information.
Feldblyum's book on Russian names has the most interesting story behind the book. It is largely based on a Russian book published in 1911 by Iser Kulisher in Zhitomir, Ukraine. The book was intended to help government bureaucrats make sense of all the variations of Jewish given names. This was a serious problem, as people were forbidden to change their name as recorded at their birth. If they were listed in a document with even the slightest variation of their name, the listing was considered a different person. To use an example from the book, if a tax list showed that Moshe paid his taxes, but his name in another register was listed as Mojshe, then he could be taxed again.
Cohn's book on Yiddish names, like Gorr's, was also published posthumously. As an academically published book it is incredibly expensive (listed at $165). For that price, you get much less than the much larger, more comprehensive (and at $85 cheaper) Beider book (or even in some ways the $29 Handbook). The introductory essays of the book are good, but the lexicon itself is a bit frustrating. For example, for a book on Yiddish names, it doesn't actually include the original Yiddish spellings in the book at all, only transliterations. Truthfully, Beider doesn't include the names in their original Yiddish either, but at least he references the Hebrew names they are based on (in Hebrew) and provides an index of the Yiddish names in Hebrew letters in the back of the book. Cohn offers an index of Hebrew names as well, but oddly transliterates those too. Her index of English names and the Yiddish equivalents is useful. I wonder if some of these shortcomings would have been fixed if Cohn had lived to finish the book herself instead of having it finished after her death.
For web sites, one place to look is the Given Name Data Bases (GNDBs) at JewishGen. Truthfully, this database drives me nuts. It appears to have been last updated in 2003. You can search for 'European' names or 'Foreign Names' which means, for example you can search for names that were from Poland which is European and see what people changed their names to in the United States which is Foreign. In reverse, you can choose a Foreign country and see name changes to a European country. The records that you see are as varied as the people who filled out the information that makes up the database. Some records provide many alternate names, some don't. It would seem the database is in need of a major overhaul, and merging into a single database would be a nice start. Also, beyond this major limitation, it doesn't actually tell you the origin of the names, but only what the person who filled out their individual information filled out. The information therefore can be very useful for trying to figure out what someone named Berish who lived in Romania and moved to Argentina might have changed their name to (Bernardo) but it's more hit-or-miss when trying to just find out about the name Berish (you nee to pick European/Foreign pairs to search and hope you get lucky).
A general site on given names called Behind the Name, has a section on Jewish names which is very useful. The site shows the etymology and history of names, and will show the language of original (Hebrew or Yiddish for example). If the name was originally in Hebrew or Yiddish, the site will also give you the name in Hebrew letters.
Another useful site, believe it or not, is Wikipedia. Obviously it's not consistent on how it deals with names, but there are many Wikipedia entries on given names. Try searching for a name and add 'given name' to the search. For example, see these entries for Israel (name) and Rebecca (given name).
What's your favorite name story? What name did it take years for you to decipher? Post your stories in the comments.
Thursday, June 16, 2011
FamilyTree DNA Upgrade Sale (June 15-22)
The upgrades that are discounted include:
| Family Finder | Was $28 | Now $19 |
| Y-DNA 12 to 25 | Was $49 | Now $35 |
| Y-DNA 12 to 37 | Was $99 | Now $69 |
| Y-DNA 12 to 67 | Was $18 | Now $14 |
| Y-DNA 25 to 37 | Was $49 | Now $35 |
| Y-DNA 25 to 67 | Was $14 | Now $11 |
| Y-DNA 37 to 67 | Was $99 | Now $79 |
| mt to FMS | Was $26 | Now $22 |
| mtPlus to FMS | Was $23 | Now $19 |
The sale runs from June 15 through June 22. To get these prices, you must log in to FamilyTree DNA using your kit number and password, and then click on the 'Special Offers' link on the left-hand navigation bar.
If you're new to genetic genealogy and want to get a discount for a new test, I suggest 'Liking' FamilyTree DNA on Facebook. They offered one-day discounts when they reached 5,000 and 10,000 followers, and have promised to do the same when they reach 15,000 followers. As I write this they're currently at 12,208 people who like their page, so it will probably be sometime in the next month or two that they will reach 15,000. If you use Facebook, then Like FamilyTree DNA and watch the Like count so you will know when they announce their sale (which will be on their Facebook page).
Tuesday, June 14, 2011
Speaking on Genetic Genealogy next week in Modi'in
I will be giving an introductory (and practical) lecture on the use of DNA for genealogy (similar to the lecture I gave in Ra'anana last month), followed by Richard Gussow, who will be furthering the theme by discussing the topic:
"The WIRTH Group – or how a “pureblood” Ashkenazi discovered his Sephardic roots – and more!"
It promises to be a very interesting discussion and I welcome everyone to come, listen and ask questions.
As with all meetings in Modi'in of the Israel Genealogical Society, the first meeting is free for interested people, so even if you're not a member of IGS you can attend this lecture for free. Of course, if you're interested in joining IGS, we'll have membership forms available (and you can take advantage of the current membership discount for the rest of the year - 100nis instead of the normal 180nis).
If you think you're going to be coming, please send me an e-mail to let me know.
Monday, June 6, 2011
1000 Fans on Facebook!
I want to thank all the fans of this site on Facebook, which now number 1000!
http://www.facebook.com/jewishgenealogy
If you're interested in following this blog a different way, check out the Follow This Blog page, which is always accessible from one of the tabs at the top of the page.
Lastly, if you like this blog and think the information provided is useful, please tell a friend about it!
If you're interested in following this blog a different way, check out the Follow This Blog page, which is always accessible from one of the tabs at the top of the page.
Lastly, if you like this blog and think the information provided is useful, please tell a friend about it!
Thursday, June 2, 2011
Blood and Frogs +1
You may have noticed recently that there has a been a small 
button popping up in Google search results and in other locations (like at the end of blog posts). This button is a new Google initiative called the +1 button that Google is trying to deploy across the Internet to help people recommend specific sites and articles. When the button is unpressed it is clear, but when you click on it it turns blue, and the number next to it increments by one. You can 'unclick' it also - just click it again and it will go back to being clear. You can try that below in the button I have in this post.
If you have a Google account (and are logged into it), then pressing this button for sites, articles and search results you like will actually change the search results people in your online social circle see when doing searches in Google. In other words, if a site you clicked on shows up in the search results of someone you know, it may then show up further up in the search results since Google knows that a friend (you) of the person searching liked that result. For those of you familiar with Digg or Liking on Facebook, this is a very similar concept, except it is fully integrated into Google which makes it very powerful (if you use Google).
This is still experimental, and who knows if Google will keep this feature in the long-run, but if you want give it a try you might already see it in your Google search results (it is being rolled out now to users of English-language search).
You can also try the button here:
Of course, if you're reading news posts in the future, or are looking at older posts on this site that you like, please press the +1 button at the end of each post to help increase its visibility on Google and I appreciate all the help I can get, so +1 away!
If you start using this feature here and on other genealogy sites around the web, this should increase the relevance of the search results you and your friends get online as more and more of your social network starts to contribute information (instead of it just being determined by a computer algorithm). I don't know yet if it will also change your own search results based on the sites you click on, but I guess that doesn't matter much since Google already knows about which sites people are visiting. Perhaps pressing +1 will rank more important than visiting the site (since you may have visited a site and not liked it).
For those interested in adding this button to your own web pages, Google has a page that will generate the code for you automatically. One thing they leave out, however, is that the link they give you will increase the count of only the page it is on, not of the site overall. For example, when this article is posted you will see it on the main page of this web site, which is different from the permanent link to this article, which is also different from the page you would see if you searched for all articles with the 'google' label. If you take the code Google gives you (from the previous link) and place it on your web site (like in the top right of the page like on this web site) it will actually give a different count for each of those views since the web address is different in each case.
Originally I figured this out by looking at how Blogger (which this site runs on) was adding the +1 buttons to posts, but it turns out the ability to direct a +1 button to a specific web address is fully documented on the +1 button API page. For example, the +1 button in the top right of the page has a specified web address for the site's home page to insure the count is for the site as a whole and not whatever page the person happens to be on at the time. Indeed each button that Google automatically adds to the bottom of each Blogger post (like on this site) links to that specific post. That's why you can have multiple versions of the button on this page and each one is specific to the post and not to the page (which could contain multiple articles).
p.s. You'd think Google would be smart enough to come up with a name that could easily be converted into a verb. People Like things on Facebook all the time (Like in the sense clicking on the Like button for a page, post or comment) and they Digg posts on sites that support Digg. When I wrote "+1 away!" above it felt a bit contrived. +1 to Facebook and Digg for coming up with the better terms...
button popping up in Google search results and in other locations (like at the end of blog posts). This button is a new Google initiative called the +1 button that Google is trying to deploy across the Internet to help people recommend specific sites and articles. When the button is unpressed it is clear, but when you click on it it turns blue, and the number next to it increments by one. You can 'unclick' it also - just click it again and it will go back to being clear. You can try that below in the button I have in this post.If you have a Google account (and are logged into it), then pressing this button for sites, articles and search results you like will actually change the search results people in your online social circle see when doing searches in Google. In other words, if a site you clicked on shows up in the search results of someone you know, it may then show up further up in the search results since Google knows that a friend (you) of the person searching liked that result. For those of you familiar with Digg or Liking on Facebook, this is a very similar concept, except it is fully integrated into Google which makes it very powerful (if you use Google).
This is still experimental, and who knows if Google will keep this feature in the long-run, but if you want give it a try you might already see it in your Google search results (it is being rolled out now to users of English-language search).
You can also try the button here:
Of course, if you're reading news posts in the future, or are looking at older posts on this site that you like, please press the +1 button at the end of each post to help increase its visibility on Google and I appreciate all the help I can get, so +1 away!
If you start using this feature here and on other genealogy sites around the web, this should increase the relevance of the search results you and your friends get online as more and more of your social network starts to contribute information (instead of it just being determined by a computer algorithm). I don't know yet if it will also change your own search results based on the sites you click on, but I guess that doesn't matter much since Google already knows about which sites people are visiting. Perhaps pressing +1 will rank more important than visiting the site (since you may have visited a site and not liked it).
For those interested in adding this button to your own web pages, Google has a page that will generate the code for you automatically. One thing they leave out, however, is that the link they give you will increase the count of only the page it is on, not of the site overall. For example, when this article is posted you will see it on the main page of this web site, which is different from the permanent link to this article, which is also different from the page you would see if you searched for all articles with the 'google' label. If you take the code Google gives you (from the previous link) and place it on your web site (like in the top right of the page like on this web site) it will actually give a different count for each of those views since the web address is different in each case.
Originally I figured this out by looking at how Blogger (which this site runs on) was adding the +1 buttons to posts, but it turns out the ability to direct a +1 button to a specific web address is fully documented on the +1 button API page. For example, the +1 button in the top right of the page has a specified web address for the site's home page to insure the count is for the site as a whole and not whatever page the person happens to be on at the time. Indeed each button that Google automatically adds to the bottom of each Blogger post (like on this site) links to that specific post. That's why you can have multiple versions of the button on this page and each one is specific to the post and not to the page (which could contain multiple articles).
p.s. You'd think Google would be smart enough to come up with a name that could easily be converted into a verb. People Like things on Facebook all the time (Like in the sense clicking on the Like button for a page, post or comment) and they Digg posts on sites that support Digg. When I wrote "+1 away!" above it felt a bit contrived. +1 to Facebook and Digg for coming up with the better terms...
My new article series on the JewishGen blog
I've started the series with an expansion of my earlier post here on the JewishGen Family Finder, called JewishGen Basics: The JewishGen Family Finder (JGFF). If you're doing Jewish Genealogy and are not using the JGFF, you should definitely go read the article and add your information to the JGFF which is a very important resource for Jewish genealogy. If you already use JGFF, but don't fully understand it, then also read the article which explains a bit about how to optimize your results using the JGFF.
If there are section or features of the JewishGen web site you'd like me to write about in future articles in this series, let me know.
If you don't know about the JewishGen Blog, make sure to check out the rest of the blog, which has contributors from across the spectrum of Jewish genealogy and in addition to information on the JewishGen site itself, provides all kinds of information of interest to anyone researching their Jewish relatives.
As always, please let me know what you think (either in the comments for the JewishGen Blog article, or in the comments for this post).
Subscribe to:
Posts (Atom)