From: Munzir T. <mun...@gm...> - 2014-02-10 13:46:13
|
Once upon a time a had a bug in gramps that it crashes all the time so I downloaded a git-svn version and manage to continue working on my family tree. Then, the bug is resolved and I tried to go back to the stable version 4.0.3. So, from the svn version: Family Trees -> Export -> Gramps XML (family tree) -> gramps.data >From the stable version: Family Trees -> Import -> gramps.data -> Import I got this error The .gramps file you are importing was made by version 4.1.0 of Gramps, while you are running an older version 4.0.3. The file will not be imported. Please upgrade to the latest version of Gramps and try again. How can I resolve this, please? -- Telecommunications and Electronics Engineer (B.Sc.) VMware Certified Associate - Data Center Virtualization (VCA-DCV) Novell Data Center Technical Specialist (DC Tech Spec) Linux Professional Institute Certified Level 1 (LPIC-1) Solaris Certified System Administrator (SCSA) International Computer Driving License (ICDL) Novell Certified Administrator (Novell CLA) Microsoft Office User Specialist (MOUS) Red Hat Certified Engineer (RHCE) IBM Certified for Power Systems Linux+ Certified Professional Master CIW Designer SUSE 11 Tech Spec |
From: Robby <zy...@ya...> - 2014-02-10 14:39:55
|
Just tried going from 4.0.3 to 3.4.6-1 and it worked OK. But have no experience with git-svn version. You could try this - The data.gramps file is a zipped xml file. You could unzip it and use a text editor to compare what you have with what GRAMPS 4.0.3 is expecting and make the necesary changes, then re-zip and import. The start of the file is where the version is stored. eg: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE database PUBLIC "-//Gramps//DTD Gramps XML 1.5.1//EN" "http://gramps-project.org/xml/1.5.1/grampsxml.dtd"> <database xmlns="http://gramps-project.org/xml/1.5.1/"> <header> <created date="2014-02-10" version="4.0.3-WinP01"/> ... OR earlier... <created date="2014-02-10" version="3.4.6-1"/> There wasn't much difference between 4.0.3 and 3.4.6-1. No idea what git-svn version gives tho. Maybe someone else can give you an easier solution. I'm still using 346 cos 347 and 403 has more bugs than I like. Robby -- View this message in context: http://gramps.1791082.n4.nabble.com/How-can-I-import-to-an-older-version-tp4664771p4664772.html Sent from the GRAMPS - User mailing list archive at Nabble.com. |
From: Munzir T. <mun...@gm...> - 2014-02-10 17:32:27
|
Thanks all (Robby, Jerome, Borgsteede) for the clarifications. I did changed the DTD and header to the stable version and now at least I can open it with gramps 4.0.3. I do remember that I got a dialog to confirm the database upgrade but I didn't get the impression any thing is wrong or dangerous. I do remember however I read on the docs that "As XML is a text-based human-readable format, you may also use it to take a look at your data. This format is compatible with the previous versions of Gramps." https://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Manage_Family_Trees So, basically, what your saying now that XML is not compatible with previous versions? May be I had misunderstood that statement? I already saved the 4.1 version db and would try to compare and migrate things manually. Thanks again for the great software and support. On 02/10/2014 05:39 PM, Robby wrote: > Just tried going from 4.0.3 to 3.4.6-1 and it worked OK. But have no > experience with git-svn version. > You could try this - > > The data.gramps file is a zipped xml file. You could unzip it and use a > text editor to compare what you have with what GRAMPS 4.0.3 is expecting and > make the necesary changes, then re-zip and import. > > The start of the file is where the version is stored. > eg: > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE database PUBLIC "-//Gramps//DTD Gramps XML 1.5.1//EN" > "http://gramps-project.org/xml/1.5.1/grampsxml.dtd"> > <database xmlns="http://gramps-project.org/xml/1.5.1/"> > <header> > <created date="2014-02-10" version="4.0.3-WinP01"/> > ... > > OR earlier... > <created date="2014-02-10" version="3.4.6-1"/> > > -- Telecommunications and Electronics Engineer (B.Sc.) VMware Certified Associate - Data Center Virtualization (VCA-DCV) Linux Professional Institute Certified Level 1 (LPIC-1) Novell Data Center Technical Specialist (DC Tech Spec) Solaris Certified System Administrator (SCSA) International Computer Driving License (ICDL) Novell Certified Administrator (Novell CLA) Microsoft Office User Specialist (MOUS) Red Hat Certified Engineer (RHCE) IBM Certified for Power Systems Linux+ Certified Professional Master CIW Designer SUSE 11 Tech Spec |
From: Jerome <rom...@ya...> - 2014-02-10 18:07:03
Attachments:
trunk.png
|
Importing data cannot implement features or editors not yet available into Gramps 4.0.x, and this does not mean that we can downgrade without problems! I suppose that you used svn, and last changes on trunk is now under git... Maybe you used a gramps-svn version generated some months ago? If you did not see the attached dialog, then maybe your are lucky because this may mean that it was before Gramps 4.0.2! So, maybe less changes on trunk against 4.0.x... Le lun. 10 févr. 2014 at 18:31, Munzir Taha <mun...@gm...> a écrit : > I do remember that I got a dialog to confirm > the database upgrade but I didn't get the impression any thing is > wrong > or dangerous. I do remember however I read on the docs that > > "As XML is a text-based human-readable format, you may also use it to > take a look at your data. This format is compatible with the previous > versions of Gramps." > https://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Manage_Family_Trees > > So, basically, what your saying now that XML is not compatible with > previous versions? May be I had misunderstood that statement? > > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Nick H. <nic...@ho...> - 2014-02-10 18:49:01
|
Munzir, Thanks for pointing this out. I have removed the statement from the wiki. The database format will depend on the revision of the code you were using. We would need a subversion revision or git hash to know the exact database format. If you were using a database with a hierarchical place structure, you have probably lost your main location data. If this is the case, let me know and I'll write something to get it back for you. You will lose tags on objects that do not support tags in the earlier version. I'm not sure what will happen with information in the data tabs of your sources and citations. Nick. On 10/02/14 17:31, Munzir Taha wrote: > Thanks all (Robby, Jerome, Borgsteede) for the clarifications. I did > changed the DTD and header to the stable version and now at least I can > open it with gramps 4.0.3. I do remember that I got a dialog to confirm > the database upgrade but I didn't get the impression any thing is wrong > or dangerous. I do remember however I read on the docs that > > "As XML is a text-based human-readable format, you may also use it to > take a look at your data. This format is compatible with the previous > versions of Gramps." > https://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Manage_Family_Trees > > So, basically, what your saying now that XML is not compatible with > previous versions? May be I had misunderstood that statement? > > I already saved the 4.1 version db and would try to compare and migrate > things manually. Thanks again for the great software and support. |
From: Munzir T. <mun...@gm...> - 2014-02-10 20:00:42
|
I'ts my first time here and you seem to be more friendly than I've even hoped. I think I can manage from here and things that are lost I can do it manually. However, I have another issue which should be easy to fix (may be I should start another thread), the "Given Name Cloud" on the dashboard would cut the given name if it had spaces! e.g Being an arabic person a name like عبد الله would appear as عبد on the dashboard which is wrong. Shouldn't you just quote or escape the give name in the code? On 02/10/2014 09:48 PM, Nick Hall wrote: > Munzir, > > Thanks for pointing this out. I have removed the statement from the wiki. > > The database format will depend on the revision of the code you were > using. We would need a subversion revision or git hash to know the > exact database format. > > If you were using a database with a hierarchical place structure, you > have probably lost your main location data. If this is the case, let me > know and I'll write something to get it back for you. > > You will lose tags on objects that do not support tags in the earlier > version. I'm not sure what will happen with information in the data > tabs of your sources and citations. > > Nick. -- Telecommunications and Electronics Engineer (B.Sc.) VMware Certified Associate - Data Center Virtualization (VCA-DCV) Linux Professional Institute Certified Level 1 (LPIC-1) Novell Data Center Technical Specialist (DC Tech Spec) Solaris Certified System Administrator (SCSA) International Computer Driving License (ICDL) Novell Certified Administrator (Novell CLA) Microsoft Office User Specialist (MOUS) Red Hat Certified Engineer (RHCE) IBM Certified for Power Systems Linux+ Certified Professional Master CIW Designer SUSE 11 Tech Spec |
From: Nick H. <nic...@ho...> - 2014-02-10 21:24:15
|
On 10/02/14 20:00, Munzir Taha wrote: > I'ts my first time here and you seem to be more friendly than I've even > hoped. I think I can manage from here and things that are lost I can do > it manually. However, I have another issue which should be easy to fix > (may be I should start another thread), the "Given Name Cloud" on the > dashboard would cut the given name if it had spaces! e.g Being an arabic > person a name like > عبد الله > would appear as > عبد > on the dashboard which is wrong. Shouldn't you just quote or escape the > give name in the code? The gramplet actually splits the given name up. In English, the given name field is used to store the first name and also middle names. Each of these names will be separated by a space. I can see this will cause problems with Arabic names. Are middle names common in Arabic names? How can we tell that two words form a single name? We could add an option to this gramplet, so that it interprets the given name field as a single name. Nick. |
From: Benny M. <ben...@gm...> - 2014-02-17 22:51:47
|
2014-02-11 16:59 GMT+01:00 Munzir Taha <mun...@gm...>: > Ok I filed a bug at > https://gramps-project.org/bugs/view.php?id=7464 > and let me reply to your questions ... > > On 02/11/2014 12:24 AM, Nick Hall wrote: > > The gramplet actually splits the given name up. In English, the given > > name field is used to store the first name and also middle names. Each > > of these names will be separated by a space. > > But I though even English given names could contain a space, e.g "Oliver > Google" ;) > > > > I can see this will cause problems with Arabic names. Are middle names > > common in Arabic names? How can we tell that two words form a single > name? > > In most Arabic countries if not all, the middle name is the father's > name and there is no way whatsoever you can tell whether this is one > name or two names unless you told to, e.g > Muhammad Ahmed > Could be a child called Muhammad and his father is Ahmed or it could be > one name and this is why I suggest you put a different text box for the > middle name like most software and applications do. > In the first case all brothers would have the Ahmed section. So it would be a patronimic part, which is stored in the surname section (click on multiple surnames), with origintype Patronimic https://www.gramps-project.org/wiki/index.php?title=Names_in_Gramps#Origin_Attributes Benny > > > We could add an option to this gramplet, so that it interprets the given > > name field as a single name. > > The generic solution I proposed would serve you better because a family > tree could have names from different cultures and they need the best of > both worlds. > > > -- > Telecommunications and Electronics Engineer (B.Sc.) > VMware Certified Associate - Data Center Virtualization (VCA-DCV) > Linux Professional Institute Certified Level 1 (LPIC-1) > Novell Data Center Technical Specialist (DC Tech Spec) > Solaris Certified System Administrator (SCSA) > International Computer Driving License (ICDL) > Novell Certified Administrator (Novell CLA) > Microsoft Office User Specialist (MOUS) > Red Hat Certified Engineer (RHCE) > IBM Certified for Power Systems > Linux+ Certified Professional > Master CIW Designer > SUSE 11 Tech Spec > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Serge N. <Ser...@fr...> - 2014-02-18 09:45:28
|
Le 17/02/2014 23:51, Benny Malengier a écrit : > > > > 2014-02-11 16:59 GMT+01:00 Munzir Taha <mun...@gm... <mailto:mun...@gm...>>: > > Ok I filed a bug at > https://gramps-project.org/bugs/view.php?id=7464 > and let me reply to your questions ... > > On 02/11/2014 12:24 AM, Nick Hall wrote: > > The gramplet actually splits the given name up. In English, the given > > name field is used to store the first name and also middle names. Each > > of these names will be separated by a space. > > But I though even English given names could contain a space, e.g "Oliver > Google" ;) > In france, we have names like "Le rhun" "Le bec" "Le ..." In some applications, we must put a dash to avoid this problem : "le-rhun" le-bec" ... So I think a space must be valid. > > > > I can see this will cause problems with Arabic names. Are middle names > > common in Arabic names? How can we tell that two words form a single name? > > In most Arabic countries if not all, the middle name is the father's > name and there is no way whatsoever you can tell whether this is one > name or two names unless you told to, e.g > Muhammad Ahmed > Could be a child called Muhammad and his father is Ahmed or it could be > one name and this is why I suggest you put a different text box for the > middle name like most software and applications do. > > > In the first case all brothers would have the Ahmed section. So it would be a patronimic part, which is stored in the surname section (click on multiple surnames), with origintype Patronimic > > https://www.gramps-project.org/wiki/index.php?title=Names_in_Gramps#Origin_Attributes > > Benny > > > > We could add an option to this gramplet, so that it interprets the given > > name field as a single name. > > The generic solution I proposed would serve you better because a family > tree could have names from different cultures and they need the best of > both worlds. > SErge |
From: Jerome <rom...@ya...> - 2014-02-10 14:51:59
|
> The .gramps file you are importing was made by version 4.1.0 of Gramps You ran trunk (git master) ... You should have seen a warning about database upgrade, no? OK, you should not use your database with git master. With this 'experimental' and 'unsafe' upgrade, you can have changes on places hiearchy, tags on all primary objects, checksums on media objects, etc ... :( See: def gramps_upgrade_17(self): """ Upgrade database from version 16 to 17. 1. This upgrade adds tags to event, place, repository, source and citation objects. 2. Data of Source becomes SourceAttributes Secondary Object 3. Add checksum field to media objects. All new features might be UNSTABLE, but the most annoying is: def upgrade_datamap_17(datamap): """ In version 16 key value pairs are stored in source and citation. These become SrcAttribute """ new_srcattr_list = [] private = False from ..lib.srcattrtype import SrcAttributeType for (key, value) in datamap.iteritems(): the_type = SrcAttributeType(key).serialize() new_srcattr_list.append((private, the_type, value)) return new_srcattr_list gramps/gen/db/upgrade.py Maybe one solution is to try to fix your .gramps for matching current stable DB scheme: https://gramps-project.org/xml/1.5.1/ https://www.gramps-project.org/wiki/index.php?title=Generate_XML#How_do_I_uncompress_the_file.3F Devs, Maybe on master we should re-enable messages like: #: ../gramps/gui/grampsgui.py:217 msgid "Danger: This is unstable code!" msgstr "" #: ../gramps/gui/grampsgui.py:218 msgid "" "This Gramps 4.1-trunk is a development release. This version is not meant " "for normal usage. Use at your own risk.\n" "\n" "This version may:\n" "1) Work differently than you expect.\n" "2) Fail to run at all.\n" "3) Crash often.\n" "4) Corrupt your data.\n" "5) Save data in a format that is incompatible with the official release.\n" "\n" "<b>BACKUP</b> your existing databases before opening them with this version, " "and make sure to export your data to XML every now and then." msgstr "" Jérôme Le lun. 10 févr. 2014 at 14:45, Munzir Taha <mun...@gm...> a écrit : > Once upon a time a had a bug in gramps that it crashes all the time > so I > downloaded a git-svn version and manage to continue working on my > family > tree. Then, the bug is resolved and I tried to go back to the stable > version 4.0.3. > > So, from the svn version: > Family Trees -> Export -> Gramps XML (family tree) -> gramps.data > >> From the stable version: >> > Family Trees -> Import -> gramps.data -> Import > > I got this error > The .gramps file you are importing was made by version 4.1.0 of > Gramps, > while you are running an older version 4.0.3. The file will not be > imported. Please upgrade to the latest version of Gramps and try > again. > > How can I resolve this, please? > > -- > Telecommunications and Electronics Engineer (B.Sc.) > VMware Certified Associate - Data Center Virtualization (VCA-DCV) > Novell Data Center Technical Specialist (DC Tech Spec) > Linux Professional Institute Certified Level 1 (LPIC-1) > Solaris Certified System Administrator (SCSA) > International Computer Driving License (ICDL) > Novell Certified Administrator (Novell CLA) > Microsoft Office User Specialist (MOUS) > Red Hat Certified Engineer (RHCE) > IBM Certified for Power Systems > Linux+ Certified Professional > Master CIW Designer > SUSE 11 Tech Spec > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Enno B. <enn...@gm...> - 2014-02-10 16:18:07
|
Munzir, > I got this error > The .gramps file you are importing was made by version 4.1.0 of Gramps, > while you are running an older version 4.0.3. The file will not be > imported. Please upgrade to the latest version of Gramps and try again. > > How can I resolve this, please? Thinking about the risks mentioned by Jerome, I suggest that you use your 4.1.0 version to export to GEDCOM, and try to see how that imports in 3.4.7 or 4.0.3. You may loose information in the process, like alternative names, and some other things, but it may be better than continuing with 4.1.0. Where you find things missing, you may look in an unzipped version of the 4.1.0 gramps file, and reconstruct from that where needed. This is not to say that 4.1.0 is guaranteed to destroy things, and I have not checked how source attributes are exported from that, nor if there will be a fix soon if they are not. It's just that 4.1.0 is experimental, so there is no guarantee on anything with that. regards, Enno |
From: Jerome <rom...@ya...> - 2014-02-10 16:39:55
|
If you did not make a lot of changes and did not use experimental features, you should be able to change structure and values into a copy of your backup. e,g. --- 4.1.gramps 2014-02-10 17:29:07.500986436 +0100 +++ 4.0.gramps 2014-02-10 17:25:55.671253662 +0100 @@ -1,15 +1,15 @@ <?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE database PUBLIC "-//Gramps//DTD Gramps XML 1.5.1//EN" +"http://gramps-project.org/xml/1.5.1/grampsxml.dtd"> +<database xmlns="http://gramps-project.org/xml/1.5.1/"> -<!DOCTYPE database PUBLIC "-//Gramps//DTD Gramps XML 1.6.0//EN" -"http://gramps-project.org/xml/1.6.0/grampsxml.dtd"> -<database xmlns="http://gramps-project.org/xml/1.6.0/"> <header> + <created date="2014-02-10" version="4.0.3"/> - <created date="2014-02-10" version="4.1.0"/> .. <places> <placeobj handle="_4ZLT6DVCWT9LTZRDCS" change="1198197326" id="P0003"> <ptitle>Ronne, Bornholm, Denmark</ptitle> - <type>Country</type> </placeobj> <placeobj handle="_61NT6D3G1JMOTO6Z7Y" change="1198197326" id="P0012"> <ptitle>Grostorp, Kristianstad Lan, Sweden</ptitle> - <type>Country</type> </placeobj> .. If you had set tag on events, had some datamap on citations, some media objects with trunk (pre-alpha 4.1.x); then this will be more difficult to downgrade content and the structure of Gramps XML. :( but not impossible! Jérôme Le lun. 10 févr. 2014 at 14:45, Munzir Taha <mun...@gm...> a écrit : > Once upon a time a had a bug in gramps that it crashes all the time > so I > downloaded a git-svn version and manage to continue working on my > family > tree. Then, the bug is resolved and I tried to go back to the stable > version 4.0.3. > > So, from the svn version: > Family Trees -> Export -> Gramps XML (family tree) -> gramps.data > >> From the stable version: >> > Family Trees -> Import -> gramps.data -> Import > > I got this error > The .gramps file you are importing was made by version 4.1.0 of > Gramps, > while you are running an older version 4.0.3. The file will not be > imported. Please upgrade to the latest version of Gramps and try > again. > > How can I resolve this, please? > > -- > Telecommunications and Electronics Engineer (B.Sc.) > VMware Certified Associate - Data Center Virtualization (VCA-DCV) > Novell Data Center Technical Specialist (DC Tech Spec) > Linux Professional Institute Certified Level 1 (LPIC-1) > Solaris Certified System Administrator (SCSA) > International Computer Driving License (ICDL) > Novell Certified Administrator (Novell CLA) > Microsoft Office User Specialist (MOUS) > Red Hat Certified Engineer (RHCE) > IBM Certified for Power Systems > Linux+ Certified Professional > Master CIW Designer > SUSE 11 Tech Spec > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Jerome <rom...@ya...> - 2014-02-10 17:19:15
|
I made some quick tests, and at least, it seems that your Places Table will be corrupted if you try to downgrade... e,g,. - <placeobj handle="_ca91ed0e3b248f7d947" change="0" id="P1849"> - <ptitle>Graves, KY, USA</ptitle> - <pname>Graves</pname> - <type>County</type> - <placeref hlink="_ca91ed0df706e82ea97"/> - </placeobj> <placeobj handle="_YS7LQCYHT8CAO1ZMTE" change="1234390627" id="P1683"> <ptitle>Mayfield, KY</ptitle> - <pname>Mayfield</pname> - <type>City</type> <coord long="-88.6367154" lat="36.7417235"/> - <placeref hlink="_ca91ed0e3b248f7d947"/> + <location city="Mayfield" county="Graves" state="KY" country="USA"/> </placeobj> A workaround if maybe to replace all place objects - from a previous safe places table (4.0.x) - into a *copy* of your backup (4.1) ! Did it some years ago with more than 65 598 (65.598) places[1] ... Then to change the namespace on Gramps XML header. Handles will be the same, except if you had created some new places with trunk! :( Anyway, this is experimental, and do not corrupt your backup files too. To use Gedcom file format is maybe like csv export ! You can loose some data and specific gramps' records[2]. [1] https://www.gramps-project.org/wiki/index.php?title=Place_database#To_re-use_your_data_stored_in_an_other_flat_database [2]https://www.gramps-project.org/wiki/index.php?title=Gramps_and_GEDCOM My dirty workaround sounds pity, but you cannot have missed the warning and links before DB upgrade! I saw a large dialog during tests, asking me to make backup before this upgrade. How many changes did you have since you make the choice to use git-svn-master with your data? Changes since your last backup under a stable (even with crash) 3.4.x/4.0.x version? Jérôme Le lun. 10 févr. 2014 at 14:45, Munzir Taha <mun...@gm...> a écrit : > Once upon a time a had a bug in gramps that it crashes all the time > so I > downloaded a git-svn version and manage to continue working on my > family > tree. Then, the bug is resolved and I tried to go back to the stable > version 4.0.3. > > So, from the svn version: > Family Trees -> Export -> Gramps XML (family tree) -> gramps.data > >> From the stable version: >> > Family Trees -> Import -> gramps.data -> Import > > I got this error > The .gramps file you are importing was made by version 4.1.0 of > Gramps, > while you are running an older version 4.0.3. The file will not be > imported. Please upgrade to the latest version of Gramps and try > again. > > How can I resolve this, please? > > -- > Telecommunications and Electronics Engineer (B.Sc.) > VMware Certified Associate - Data Center Virtualization (VCA-DCV) > Novell Data Center Technical Specialist (DC Tech Spec) > Linux Professional Institute Certified Level 1 (LPIC-1) > Solaris Certified System Administrator (SCSA) > International Computer Driving License (ICDL) > Novell Certified Administrator (Novell CLA) > Microsoft Office User Specialist (MOUS) > Red Hat Certified Engineer (RHCE) > IBM Certified for Power Systems > Linux+ Certified Professional > Master CIW Designer > SUSE 11 Tech Spec > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Enno B. <enn...@gm...> - 2014-02-10 21:42:52
|
Munzir, > Thanks all (Robby, Jerome, Borgsteede) for the clarifications. I did > changed the DTD and header to the stable version and now at least I can > open it with gramps 4.0.3. But like Jerome wrote, you will get a problem with places, so although it opens, I suggest that you don't actually use it. > I do remember that I got a dialog to confirm > the database upgrade but I didn't get the impression any thing is wrong > or dangerous. I do remember however I read on the docs that > > "As XML is a text-based human-readable format, you may also use it to > take a look at your data. This format is compatible with the previous > versions of Gramps." > https://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Manage_Family_Trees > > So, basically, what your saying now that XML is not compatible with > previous versions? May be I had misunderstood that statement? The statement was true between 3.4 and 4.0, but when you tried the version from SVN, you got 4.1, and that has a different XML. > I already saved the 4.1 version db and would try to compare and migrate > things manually. Thanks again for the great software and support. You're welcome. I hope you can use the information in the 4.1 XML to reconstruct any data that you added after your latest 3.4 or 4.0 backup. regards, Enno |
From: Benny M. <ben...@gm...> - 2014-02-17 23:11:11
|
2014-02-10 22:37 GMT+01:00 Enno Borgsteede <enn...@gm...>: > Munzir, > > Thanks all (Robby, Jerome, Borgsteede) for the clarifications. I did > > changed the DTD and header to the stable version and now at least I can > > open it with gramps 4.0.3. > But like Jerome wrote, you will get a problem with places, so although > it opens, I suggest that you don't actually use it. > > I do remember that I got a dialog to confirm > > the database upgrade but I didn't get the impression any thing is wrong > > or dangerous. I do remember however I read on the docs that > > > > "As XML is a text-based human-readable format, you may also use it to > > take a look at your data. This format is compatible with the previous > > versions of Gramps." > > > https://www.gramps-project.org/wiki/index.php?title=Gramps_4.0_Wiki_Manual_-_Manage_Family_Trees > > > > So, basically, what your saying now that XML is not compatible with > > previous versions? May be I had misunderstood that statement? > The statement was true between 3.4 and 4.0, but when you tried the > version from SVN, you got 4.1, and that has a different XML. > To be exact, the warning means: a new version is compatible with an old in the sense that an old can be automatically converted to a new. The other way, from new to old, is not possible. Just like you cannot load a current website in IE6, although all is officially still html. I updated Nicks change to the wiki in that regard Apart from that, using git-svn trunk means you cannot go back to stable 4.0. Trunk prepares for 4.1, but is not stable yet. As Jerome says, don't use for your actual work just yet. Benny > I already saved the 4.1 version db and would try to compare and migrate > > things manually. Thanks again for the great software and support. > You're welcome. I hope you can use the information in the 4.1 XML to > reconstruct any data that you added after your latest 3.4 or 4.0 backup. > > regards, > > Enno > > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > |
From: Munzir T. <mun...@gm...> - 2014-02-11 15:59:50
|
Ok I filed a bug at https://gramps-project.org/bugs/view.php?id=7464 and let me reply to your questions ... On 02/11/2014 12:24 AM, Nick Hall wrote: > The gramplet actually splits the given name up. In English, the given > name field is used to store the first name and also middle names. Each > of these names will be separated by a space. But I though even English given names could contain a space, e.g "Oliver Google" ;) > I can see this will cause problems with Arabic names. Are middle names > common in Arabic names? How can we tell that two words form a single name? In most Arabic countries if not all, the middle name is the father's name and there is no way whatsoever you can tell whether this is one name or two names unless you told to, e.g Muhammad Ahmed Could be a child called Muhammad and his father is Ahmed or it could be one name and this is why I suggest you put a different text box for the middle name like most software and applications do. > We could add an option to this gramplet, so that it interprets the given > name field as a single name. The generic solution I proposed would serve you better because a family tree could have names from different cultures and they need the best of both worlds. -- Telecommunications and Electronics Engineer (B.Sc.) VMware Certified Associate - Data Center Virtualization (VCA-DCV) Linux Professional Institute Certified Level 1 (LPIC-1) Novell Data Center Technical Specialist (DC Tech Spec) Solaris Certified System Administrator (SCSA) International Computer Driving License (ICDL) Novell Certified Administrator (Novell CLA) Microsoft Office User Specialist (MOUS) Red Hat Certified Engineer (RHCE) IBM Certified for Power Systems Linux+ Certified Professional Master CIW Designer SUSE 11 Tech Spec |
From: Nick H. <nic...@ho...> - 2014-02-11 17:22:44
|
On 11/02/14 15:59, Munzir Taha wrote: > Ok I filed a bug at > https://gramps-project.org/bugs/view.php?id=7464 > and let me reply to your questions ... Thanks for reporting this as a bug. Benny is probably the best person to ask about this. Nick. |
From: Enno B. <enn...@gm...> - 2014-02-11 18:30:22
|
Nick, > On 11/02/14 15:59, Munzir Taha wrote: >> Ok I filed a bug at >> https://gramps-project.org/bugs/view.php?id=7464 >> and let me reply to your questions ... > Thanks for reporting this as a bug. Benny is probably the best person > to ask about this. Well, I'm not Benny, but I don't think that keeping the given names together will work, because that destroys the purpose of the name cloud for many others. And adding a middle name won't help either, because it is far from what you really need to cover all names in the world. The real solution is to split a name into a sequence of parts, like we already have surnames in Gramps. When this is done for all parts, the given name can be put anywhere, including at the end, like in Vietnam and other countries in the far east. Same for middle name, father's name, etc. Many programs don't support this yet, but right now, adding a middle name field is a waste of time. Once you do this, do it right, like GedcomX 1.0. [1] regards, Enno [1] https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#name-form |
From: Nick H. <nic...@ho...> - 2014-02-11 19:10:02
|
On 11/02/14 18:30, Enno Borgsteede wrote: >> On 11/02/14 15:59, Munzir Taha wrote: >>> >>Ok I filed a bug at >>> >>https://gramps-project.org/bugs/view.php?id=7464 >>> >>and let me reply to your questions ... >> >Thanks for reporting this as a bug. Benny is probably the best person >> >to ask about this. > Well, I'm not Benny, but I don't think that keeping the given names > together will work, because that destroys the purpose of the name cloud > for many others. And adding a middle name won't help either, because it > is far from what you really need to cover all names in the world. My questions were trying to establish if there was anything I could do to provide a quick solution for Arabic names. > The real solution is to split a name into a sequence of parts, like we > already have surnames in Gramps. When this is done for all parts, the > given name can be put anywhere, including at the end, like in Vietnam > and other countries in the far east. Same for middle name, father's > name, etc. Benny made the change for storing multiple surnames. Ideally we should store each part of a name separately, but that would require a database change. I'll leave this for someone else to do. :) Nick. |
From: Enno B. <enn...@gm...> - 2014-02-11 20:27:20
|
Nick, > On 11/02/14 18:30, Enno Borgsteede wrote: >>> On 11/02/14 15:59, Munzir Taha wrote: >>>>>> Ok I filed a bug at >>>>>> https://gramps-project.org/bugs/view.php?id=7464 >>>>>> and let me reply to your questions ... >>>> Thanks for reporting this as a bug. Benny is probably the best person >>>> to ask about this. >> Well, I'm not Benny, but I don't think that keeping the given names >> together will work, because that destroys the purpose of the name cloud >> for many others. And adding a middle name won't help either, because it >> is far from what you really need to cover all names in the world. > My questions were trying to establish if there was anything I could do > to provide a quick solution for Arabic names. For that, I think that your initial idea to have a check box decide to take the first word or the full given name to be displayed in the cloud is good for now. Munzir's case of the father's name as middle name can already be solved in current Gramps [1]. Just put the middle name in the first surname row, and mark the family name in the second row as primary. > >> The real solution is to split a name into a sequence of parts, like we >> already have surnames in Gramps. When this is done for all parts, the >> given name can be put anywhere, including at the end, like in Vietnam >> and other countries in the far east. Same for middle name, father's >> name, etc. > Benny made the change for storing multiple surnames. Ideally we should > store each part of a name separately, but that would require a database > change. I'll leave this for someone else to do. :) OK. I see no hurry for reasons mentioned above. We may also wait for GedcomX to be more established. regards, Enno [1] https://www.gramps-project.org/wiki/index.php?title=File:EditPerson-PersonWindow-40.png |