"In most European (and Europe-derived) cultures, the given name usually comes before the family name (though generally not in lists and catalogs), and so is known as a forename or first name; but the family name traditionally comes first in Hungary, parts of Africa and most of East Asia (e.g., China, Japan, Korea and Vietnam). In China and Korea, even part of the given name may be shared among all members of a given generation in a family and the family's extensions, to differentiate those generations from other generations."
Currently the names are displayed in English order, but this is VERY disturbing.
Please fix this bug, so when the Language is Hungarian, the name ordering should change to "Family name Given name".
I agree and fully support this request, it's strange that the developers published a hungarian version of this site and - I bet - they didn't even know about this problem. Fix it soon, or you probably lose some 10-15 million hungarians in this site.
Thank you for writing us regarding the product suggestion. I would like to inform you though that we already have these options in the Family Tree Builder by going to Edit > Search (or shortcut Ctrl F on the keyboard).
You have there comprehensive searching abilities which let you have much better control of what you are exactly looking for.
Please let me know if you still need more information about it.
I too seem to have difficulty in query writing- Perhaps you could Actually demonstrate HOW I can solve this issue
In pawing over my data recently I discovered that there were females that did not have a married name assigned. Just over 800 to be more accurate.
To prepare a list of those individuals requires a query like:
Sex MATCHES: FEMALE
Marriage date: EXISTS
Married name: DOES NOT EXIST
Quite a simple query really- but WHERE can I use it?
Similarly I discovered that when I imported my GEDCOM file into Myheritage FTB from its original form in Personal Ancestral File (PAF) I had often used a date determined filed that represents the condition that exists for a large part of my research In South Australia and uses the published Death Index which conclude in 1972.
Thus I had some death dates as After 1972.
So to find those entries and seek to either update or amend them- requires a Query thus:
Death date: contains AFTER.
Quite a simple query really- but WHERE can I use it?
So to get around this problem- I had to export a New GEDCOM out of Myheritage FTB - create and import that GEDCOM in PAF and write the queries-.
THEN in parallel- with both Myheritage FTB AND PAF open- edit my through the list.
Am I missing something here- or is Myheritage just not quite up to query involvement?
Your theory of CTRL F and inputting your requirments does not seem to cope with what I need.
I understand that you have some difficulty with our system, and so I've included some screenshots to make it a little bit clearer for you. The red circles are the first steps you should do (and the first screen you will be presented as if you go to Edit > Search).
If you change the Fact type on an existing Fact from say Settlement to a custom Fact, say Electoral Roll, any attached photos/documents attached to the fact become detached after selecting OK. The photos/documents then have to be reattached to the fact, which is a pain if you have a lot to change as I did.
When saving a tree with a differnet name, the SmartMatches are NOT saved!!!! It would save MONTHS of work if that would be done. If I want to publish my NEW tree (saved with another name) and the SmartMatches were also saved I didn´t have to confirm ALL former matches again. In my tree it is about 100 000 matshes thas are lost.
You are right in that if you use the "save as" function in FTB, you create a new project with a new ID. When this project is later published to the MyHeritage site, it will be treated as a new tree and new Smart Matches will be calculated for it.
A possible workaround for your problem is to use the "rename" function instead. Go to File > Close project, and then to File > Manage Trees. In this menu you will be able to rename your tree without changing its ID.
I've noticed when merging info from smart matches that people use different formats for names - some use all lower case, some capitalised, and some have the last name in all capitals.
To be consistent, I have spent much time retyping names into the format I prefer.
It would be a big help is Family Tre Builder has a format option that automatcally reformatted names and addresses according to formats selected in the options menu. As well as making it automatic on entering or merging a new name, there could be some way of changing the format of all names in the database.
These could be:
for names (first or last) - all lower, capitalised, all upper
for addresses - similar options for suburbs, towns, states, countries
I agree. However, I (and many others) do tend to use all upper case to easily locate the immigrants to America. I would like to see a way to easily tag (Different color font or additional symbol) for both Immigrant and DAR/SAR ancestors.
I also re-type the names, and I use the protocol suggested by MyHeritage somewhere in the Help section, or at least that is the way it is done in their example. I do it the same as my name (in this Reply). Which is normal and correct for everyday use. Using Family Tree Builder you will get a mis-match if the entry you are trying to merge is set out differently; but if it is a name recently used and the programme recognises it you can highlight the name and hit (I think) the spacebar and the name will be changed.
I also do a lot of changing of place names, always inserting the (town or suburb), the State, AND the country, which can be important; I was born in Rochester, Victoria, Australia, and I have been told that there around forty towns of that name in the world. Regards, Geoff
Sorry I don't like the changes you made to the Web usage of My Heritage site, is there anyway of returing to the old format?
The new method is slow and awkward to use, data is not easy to view anymore and editing takes twice as long as before. If this is not possable I will seriously look else where, as finding it very frustrating to use now.