From: Lorenzo C. <l_c...@ev...> - 2003-08-01 20:48:34
|
Hi everyone, reading the manual, I noticed that GRAMPS shows marriage dates in Family View when available. Why were my marriage dates not displayed? I had a look at the source code and found out that marriage date is shown when the event is of type "Marriage". I opened data.gramps with XEmacs and found out that all (but two) marriage events were of type "Matrimonio", which is the Italian word for "Marriage". Thus, I tried to replace "Matrimonio" for "Marriage" using the GRAMPS' standard tool, but I was unsuccessful because I couldn't find any "Marriage" to substitute for. Replacing "Matrimonio" from within XEmacs fixed the problem and all marriage dates are now shown. I noticed also that there are several others event types which are translated in Italian in my data.gramps file. Is that correct? -- email: lor...@em... Jabber: lo...@li... Fingerprint: 8CDD 3408 53B2 6122 99DA EE37 1523 68FC D906 4C08 Vuoi aiutarci ad avere le descrizioni dei pacchetti Debian in italiano? http://ddtp.debian.org/ |
From: Don A. <dal...@us...> - 2003-08-01 21:42:41
|
Lorenzo Cappelletti wrote: >Hi everyone, > >reading the manual, I noticed that GRAMPS shows marriage dates in Family >View when available. Why were my marriage dates not displayed? > >I had a look at the source code and found out that marriage date is >shown when the event is of type "Marriage". I opened data.gramps with >XEmacs and found out that all (but two) marriage events were of type >"Matrimonio", which is the Italian word for "Marriage". > >Thus, I tried to replace "Matrimonio" for "Marriage" using the GRAMPS' >standard tool, but I was unsuccessful because I couldn't find any >"Marriage" to substitute for. Replacing "Matrimonio" from within XEmacs >fixed the problem and all marriage dates are now shown. > > What GRAMPS tries to do is keep the "standard" event types (ones with GEDCOM equivalents), such as "Marriage", "Birth", "Death", etc. in English. This makes it easier to translate in and out of GEDCOM. It also makes it easier to do searches for several commonly used events (again, like marriage, birth, and death) when it needs to display information. It also means that if you send a database to someone using Russian and Italian database, the user will see the standard types correctly translated into the native language. If you enter an event that does not match the standard types, it will keep it as a text string. So if you enter it in Italian, it will remain in Italian, Russian will remain Russian, and Pig Latin will remain Pig Latin. Of course, this means that a lot of odd mapping has to be done by the program, and in some cases, there may be a few bugs. If you can provide steps to duplicate the problem (how you got Matrimonio instead of Marriage in the XML file), it would help me to track it down and fix it. There is a good chance that we already fixed the problem (it sounds familiar), and the data was entered before the problem was fixed. Don |
From: Lorenzo C. <l_c...@ev...> - 2003-08-03 09:42:12
Attachments:
data.gramps
|
Don Allingham <dal...@us...>, Fri 01 Aug 2003 15:30 -0600: > It also means that if you send a database to someone using Russian and > Italian database, the user will see the standard types correctly > translated into the native language. This sounds perfectly reasonable. It's exactly what I'd expect from an internationalized program like GRAMPS. > If you enter an event that does not match the standard types, it will > keep it as a text string. So if you enter it in Italian, it will remain I don't think I did that. > If you can provide steps to duplicate the problem (how you got > Matrimonio instead of Marriage in the XML file), it would help me to Ok, let's go. I created a new database from scratch (LANG=it_IT@euro, of course). I entered a new person, a man, his birth and death, then a woman. I went to Family View and added a relationship between them of type Married, then an event of type Marriage. What I got is shown on the attached file. As you can see data.gramps includes Italian words such as "Sposato/a" and "Matrimonio". Other event types I spotted in my own database are: Morte alternativa -> Alternative Death Emigrazione -> Emigration Occupazione -> Occupation Nascita alternativa -> Alternative Birth Battesimo -> Baptism/Christening Ordinazione -> Ordination Censimento -> Census Testamento -> Will Numero di figli -> Numbero of Children Fonte -> Source Data -> Date Luogo -> Place Autore -> Author Sposato/a -> Married Matrimonio -> Marriage PS (for your reference): the first name I typed for the man was just an "A". No other data were entered. Clicking on the OK button I got the following error: Traceback (most recent call last): File "/usr/share/gramps/EditPerson.py", line 1442, in on_apply_person_clicked self.callback(self,self.add_places) File "/usr/share/gramps/gramps_main.py", line 1642, in new_after_edit self.redisplay_person_list(epo.person) File "/usr/share/gramps/gramps_main.py", line 1694, in redisplay_person_list self.add_to_person_list(person,1) File "/usr/share/gramps/gramps_main.py", line 1690, in add_to_person_list self.goto_active_person() File "/usr/share/gramps/gramps_main.py", line 1394, in goto_active_person self.ptabs.set_current_page(self.model2page[model]) KeyError: <ListModel.ListModel instance at 0x8685d8c> -- email: lor...@em... Jabber: lo...@li... Fingerprint: 8CDD 3408 53B2 6122 99DA EE37 1523 68FC D906 4C08 Vuoi aiutarci ad avere le descrizioni dei pacchetti Debian in italiano? http://ddtp.debian.org/ |
From: Alex R. <sh...@al...> - 2003-08-07 04:23:27
|
On Sun, Aug 03, 2003 at 11:36:35AM +0200, Lorenzo Cappelletti wrote: > Don Allingham <dal...@us...>, Fri 01 Aug 2003 15:30 -0600: > > > > It also means that if you send a database to someone using Russian and > > Italian database, the user will see the standard types correctly > > translated into the native language. [snip] > > If you enter an event that does not match the standard types, it will > > keep it as a text string. So if you enter it in Italian, it will remain [snip] > > If you can provide steps to duplicate the problem (how you got > > Matrimonio instead of Marriage in the XML file), it would help me to [steps] I just committed a bunch of little fixes that should provide the right functionality for the newly entered data. Since it's a lot of little things it is quite likely that I may have missed something somewhere. If more people can check it with non-English LANGs it would be of great help. As for the data saved by previous versions of gramps, I'm facing a dilemma here. If gramps assumes that the data is correct with the above strategy, then everything in XML that is not English standard type will be interpreted as a custom type and just kept as a string. This means that Italian strings will be kept Italian. If, however, we attempt to translate every type to decide whether it's a custom type it can slow down the already slow parsing process. One has to also keep in mind that the same applies to personal events, personal and family attributes, etc. Although it seems that it's only the family events that were out of wack now :-) An alternative solution for handling old data can be providing a transition script that would go through the XML once and correct these issues. But the best thing IMHO would be using the version number which is stored in the XML itself. Everything created with up to 0.9.3-1 should undergo an attempt of the translation. Then we may display an info dialog saying that the incosistency has been corrected and you need a save to make that correction permanent. What are the opinions on this? Do nothing vs always translate vs look at the version? Alex -- Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |
From: Lorenzo C. <l_c...@ev...> - 2003-08-08 21:43:10
|
Alex Roitman <sh...@al...>, Wed 06 Aug 2003 23:22 -0500: > Everything created with up to 0.9.3-1 should undergo an attempt of the > translation. Then we may display an info dialog saying that the > incosistency has been corrected and you need a save to make that > correction permanent. I would also warn the user to make a backup of the old data and ask them to check out the database for mistakes. I don't think this is a dangerous process, but you never know. -- email: lor...@em... Jabber: lo...@li... Fingerprint: 8CDD 3408 53B2 6122 99DA EE37 1523 68FC D906 4C08 Vuoi aiutarci ad avere le descrizioni dei pacchetti Debian in italiano? http://ddtp.debian.org/ |
From: Alex R. <sh...@al...> - 2003-08-11 01:19:16
|
On Wed, Aug 06, 2003 at 11:22:24PM -0500, Alex Roitman wrote: > Do nothing vs always translate vs look at the version? Hi all, Just to bring everybody up to date: we used to have a problem in that the family relations, the event types and the attributes, both personal and family, were saved in XML in $LANG. The correct functionality would be English for all the standard events, relations, and attributes. Previously, the thing was fixed for the newly created data. The question was open as to what to do with the data created by prior versions of gramps, which still has $LANG in place of English for all standard relations/events/attributes (referred to as "rea" in the following text for brevity :-). I just checked in a solution which attempts to translate the data upon reading. It probably slows down the parsing process somewhat, but I don't think it is a considerable slowdown because these data usually constitute a small portion of the overall data. I might be wrong here, so if more people can try reading their XML data with current CVS and with the latest release and provide a clue to the performance price, it would be of great help. Another remark concerning these issues. If everything is done right, the standard "rea" should be in English after they are read from the file. Various editing points convert them to $LANG and then back, so that all the data in database (in memory) should be in English. This means the conversion on save is not necessary anymore. Right now we still have it enabled, but it probably is an overkill. If we remove conversion on save, we would expose places where we still have holes (i.e. where the memory data is not English). This way we may correct the issues which presently would go unnoticed. On the other hand, present approach safely creates proper datafiles which can be shared between languages. I would love to hear opinions from interested parties on this matter :-) Alex -- Alexander Roitman http://ebner.neuroscience.umn.edu/people/alex.html Dept. of Neuroscience, Lions Research Building 2001 6th Street SE, Minneapolis, MN 55455 Tel (612) 625-7566 FAX (612) 626-9201 |