https://gramps-project.org/wiki/api.php?action=feedcontributions&user=Fsmunoz&feedformat=atomGramps - User contributions [en]2024-03-29T01:15:37ZUser contributionsMediaWiki 1.31.3https://gramps-project.org/wiki/index.php?title=GEPS_021:_Additional_Name_Fields&diff=44720GEPS 021: Additional Name Fields2013-02-28T01:37:08Z<p>Fsmunoz: /* Introduction */</p>
<hr />
<div>'''Finished''' included in Gramps 3.3<br />
<br />
''This Gramps Enhancement Proposal is to add new fields to the name object so as to better store a person's name for several cultures. Also GUI refinements are proposed''.<br />
<br />
= New Nick Name Fields =<br />
== Nick Name ==<br />
A field for a nick name is added. Many people like to store nick name as part of the name, while now it can only be stored as an attribute. Many people use callname, but that is wrong use of that field. The Nick Name is for a nick name of a single person and will be a new name field.<br />
<br />
== Family Nick Name ==<br />
A field for a nick name used to indicate the family. <br />
<br />
'''Definition''': In some cultures, when a family name is common, family<br />
nicknames are used on documents to indicate the specific branch.<br />
Sometimes these family nicknames are even used on legal documents.<br />
<br />
Examples: mountain villages in Switserland, Austria, Dalmatia. Sometimes a family nickname becomes an official name after some time. <br />
<br />
'''Question''': Is this a good English word for this practice?<br />
<br />
= Minor User interface changes =<br />
== Relabel Given Name==<br />
''Given name'' is relabelled in the UI as ''Given name(s)''.<br />
<br />
== Validate Callname ==<br />
Callname becomes a validated field (like eg date, longitude). That is, it becomes red if the callname is not present in the given name(s).<br />
<br />
= Surname redesign =<br />
== Introduction ==<br />
In several cultures people have two or more surnames. Examples: <br />
<br />
# Cándida Sánchez de la Torre: here Sánchez and Torre are the surnames.<br />
# Santiago Ramón y Cajal: here Ramón and Cajal are the surnames.<br />
# Portugal/Brazil: 4 surnames is common: Given Name(s) | Mother Surname(s)| Father Surname(s) <br />
# Joaquim de Lima e Silva<br />
# García Álvarez de Toledo y Carrillo de Toledo [http://es.wikipedia.org/wiki/Garc%C3%ADa_%C3%81lvarez_de_Toledo_y_Carrillo_de_Toledo]<br />
# José de Mascarenhas da Silva e Lencastre [http://pt.wikipedia.org/wiki/Jos%C3%A9_de_Mascarenhas_da_Silva_e_Lencastre,_Duque_de_Aveiro]<br />
<br />
=== What is the problem?===<br />
====Let's discuss: García Álvarez de Toledo y Carrillo de Toledo====<br />
<br />
* How should it be parsed? How many surnames are in it? Well, García is a given name that is now seen only as a surname, but things were different in the past. It seems that "Carrillo de Toledo" would be a second surname, but there are other problems.<br />
* Is "Álvarez" a real patronymic? This means García is the child of some Álvaro (possibly "de Toledo", but no guarantee). His children will probably use the "Garcés" (or even "García") as patronymic and, possibly, "de Toledo" as surname. This scheme was valid until ca. 1200. In this case, Álvarez should go into the patronymic field or, as is common, as part of the given names. "de" would go into the surname prefix field.<br />
* Is "Álvarez" a false patronymic? In this case, his father was not Álvaro, but he got his name (given plus patronymic) from some ancestor or relative of notice named "García Álvarez" (not necessarily "de Toledo"). In this case, the best coding is probably the same as for real patronymics except that context does not help a lot. This is after ca. 1200.<br />
* Is it a non fixed part of the surname? It is a dark period where patronymics start being inherited but they have not solidified. In this case, García's father was "Álvarez de Toledo" but some of García's siblings would be just "de Toledo", as would some of his children. Some of them might even have a different patronymic. In this case, IMHO, I think it is best to put all of "Álvarez de" as surname prefix. Otherwise it would sort García under "A" and only an amateur would want that.<br />
* Is it a solidified part of the surname? In this case "Álvarez de Toledo" is uniformly inherited as a block and exceptions are rare. All of it should go into the surname (and sort under "A").<br />
<br />
====Let's discuss: Maria Venancia Dávalos de Rivera Mendoza Mate de Luna y Córdova====<br />
<br />
In reading page 64 of the 4th volume of Solares Montañeses by Mateo Escagedo Salmón, I find that José Gregorio Ceballos el Caballero (that's just one surname, BTW) married "Maria Venancia Dávalos de Rivera Mendoza Mate de Luna y Córdova". From the context I make the educated guess that those are four sunames: Dávalos de Rivera, Mendoza, Mate de Luna and Córdova. It would be nice to record that, especially since there is no explanation in the source of that "Mate de Luna", that flags the possibility that the source is wrong or an interesting line of research.<br />
<br />
== Proposed Solution: surname list == <br />
<br />
The proposal is to introduce:<br />
# In the UI and not editable: Formatted Name. This is a field indicating the full name as given upto now. So it has the same function as the title bar now in the person editor. However, the format is fixed and not changeable: given names - surnames. This field is to give a quick overview of the total name<br />
# In the UI and not editable: Sort Name. This is the field indicating on what the name is normally sorted in the grouped view and some reports. This field shows or the primary surname, or the group name if that is set. This field is to give a quick overview of how the name will be sorted. <br />
# Surname list: the surname consist of a list of surnames. The user sets prefix, type, connector as per his desires. One surname must be set as the primary surname. Note that surname does '''not''' have a suffix, that remains a global name field (used for eg Junior or The Third). <br />
# Quick data entry. We do not want to slow down entry of names for people with simple names. Therefore, the user interface shows all options of a single surname, and the user can add extra surnames via an add button.<br />
# Patronymic is deprecated. It becomes a type of surname (a boolean value). At the same time, Matronymic [http://en.wikipedia.org/wiki/Matronym] is added. This is stored in a derivation field, indicating how the name came about: inherited (assumed default), patronymic, matronymic, ... . What others??<br />
# With many surnames, users quickly want to know if a surname is derived from the family of the mother, or from the family of the father. Mother side, Father side allow to indicate this.<br />
<br />
== Details ==<br />
<br />
Example of the surname list: <br />
<br />
'''Formatted Name''': José de Mascarenhas da Silva e Lencastre<br />
<br />
'''Sort''': Mascarenhas<br />
<br />
{| cellpadding="5" cellspacing="0" border="1"<br />
!order <br />
! prefix <br />
! surname <br />
! primary? <br />
! connector to next? <br />
! derivation <br />
|-<br />
|1 <br />
| de <br />
| Mascarenhas <br />
| Y <br />
| <br />
| inherited<br />
|-<br />
|2 <br />
| da <br />
| Silva <br />
| N <br />
|e <br />
| inherited <br />
|-<br />
|3 <br />
| <br />
| Lencastre <br />
| N <br />
| <br />
| inherited <br />
|}<br />
<br />
surname field: de Mascarenhas da Silva e Lencastre<br />
<br />
'''Changes from previous designs''':<br />
* no mother side field or father side field: This can be shown in UI by scanning the parents. No need to store it as that will lead to conflicts<br />
* no suffix field in the surname, only prefix and connector<br />
* derivation type instead of patronymic, matronymic. Derivation type of a surname can be: inherited (assumed), patronymic, matronymic. Do we need to consider other? Eg Taken, Given?? <br />
<br />
= XML support=<br />
== Gramps 3.2 xml 1.3.0 == <br />
Name is now defined as:<br />
<br />
<define name="person-content"><br />
...<br />
<zeroOrMore><element name="name"><br />
<ref name="name-content"/><br />
</element></zeroOrMore><br />
<optional><element name="nick"><text/></element></optional><br />
...<br />
</define><br />
<br />
<define name="name-content"><br />
<optional><attribute name="alt"><choice><br />
<value>0</value><br />
<value>1</value><br />
</choice></attribute></optional><br />
<optional><attribute name="priv"><br />
<ref name="priv-content"/><br />
</attribute></optional><br />
<optional><attribute name="type"><choice><br />
<value>Also Known As</value><br />
<value>Birth Name</value><br />
<value>Married Name</value><br />
<value>Other Name</value><br />
</choice></attribute></optional><br />
<optional><attribute name="sort"><text/></attribute></optional><br />
<optional><attribute name="display"><text/></attribute></optional><br />
<optional><element name="first"><text/></element></optional><br />
<optional><element name="call"><text/></element></optional><br />
<optional><element name="last"><br />
<text/><br />
<optional><attribute name="prefix"><text/></attribute></optional><br />
<optional><attribute name="group"><text/></attribute></optional><br />
</element></optional><br />
<optional><element name="suffix"><text/></element></optional><br />
<optional><element name="patronymic"><text/></element></optional><br />
<optional><element name="title"><text/></element></optional><br />
<optional><ref name="date-content"/></optional><br />
<zeroOrMore><element name="noteref"><br />
<ref name="noteref-content"/><br />
</element></zeroOrMore><br />
<zeroOrMore><element name="sourceref"><br />
<ref name="sourceref-content"/><br />
</element></zeroOrMore><br />
</define><br />
<br />
In above ''alt'' indicates an alternative name<br />
<br />
== Gramps 3.3 xml 1.4.0 == <br />
The new xml would be<br />
<br />
<define name="person-content"><br />
...<br />
<zeroOrMore><element name="name"><br />
<ref name="name-content"/><br />
</element></zeroOrMore><br />
...<br />
</define><br />
<br />
<define name="name-content"><br />
<optional><attribute name="alt"><choice><br />
<value>0</value><br />
<value>1</value><br />
</choice></attribute></optional><br />
<optional><attribute name="priv"><br />
<ref name="priv-content"/><br />
</attribute></optional><br />
<optional><attribute name="type"><choice><br />
<value>Also Known As</value><br />
<value>Birth Name</value><br />
<value>Married Name</value><br />
<value>Other Name</value><br />
</choice></attribute></optional><br />
<optional><attribute name="sort"><text/></attribute></optional><br />
<optional><attribute name="display"><text/></attribute></optional><br />
<optional><element name="first"><text/></element></optional><br />
<optional><element name="call"><text/></element></optional><br />
<optional><element name="nick"><text/></element></optional><br />
<optional><element name="familynick"><text/></element></optional><br />
<optional><element name="group"><text/></element></optional><br />
<zeroOrMore><element name="surname"><br />
<ref name="surname-content"/><br />
</element></zeroOrMore><br />
<optional><element name="suffix"><text/></element></optional><br />
<optional><element name="title"><text/></element></optional><br />
<optional><ref name="date-content"/></optional><br />
<zeroOrMore><element name="noteref"><br />
<ref name="noteref-content"/><br />
</element></zeroOrMore><br />
<zeroOrMore><element name="sourceref"><br />
<ref name="sourceref-content"/><br />
</element></zeroOrMore><br />
</define><br />
<br />
<define name="surname-content"><br />
<element name="surname"><br />
<text/><br />
<optional><attribute name="prefix"><text/></attribute></optional><br />
<optional><attribute name="primary"><choice><br />
<value>0</value><br />
<value>1</value><br />
</choice></attribute></optional><br />
<optional><attribute name="derivation"><choice><br />
<value>inherited</value><br />
<value>patronymic</value><br />
<value>matronymic</value><br />
<value>other</value><br />
</choice></attribute></optional><br />
<optional><attribute name="connector"><text/></attribute></optional><br />
</element><br />
</define><br />
<br />
=GEDCOM import/export=<br />
<br />
== GEDCOM definition ==<br />
<br />
n NAME <NAME_PERSONAL> {1:1}<br />
+1 NPFX <NAME_PIECE_PREFIX> {0:1}<br />
+1 GIVN <NAME_PIECE_GIVEN> {0:1}<br />
+1 NICK <NAME_PIECE_NICKNAME> {0:1}<br />
+1 SPFX <NAME_PIECE_SURNAME_PREFIX> {0:1}<br />
+1 SURN <NAME_PIECE_SURNAME> {0:1}<br />
+1 NSFX <NAME_PIECE_SUFFIX> {0:1}<br />
+1 <<SOURCE_CITATION>> {0:M}<br />
+2 <<NOTE_STRUCTURE>> {0:M}<br />
+2 <<MULTIMEDIA_LINK>> {0:M}<br />
+1 <<NOTE_STRUCTURE>> {0:M}<br />
<br />
NAME_PERSONAL: = {Size=1:120}<br />
[<br />
<TEXT> |<br />
/<TEXT>/ |<br />
<TEXT> /<TEXT>/ |<br />
/<TEXT>/ <TEXT> |<br />
<TEXT> /<TEXT>/ <TEXT><br />
] <br />
<br />
NAME_PIECE_GIVEN: = {Size=1:120}<br />
[ <NAME_PIECE> | <NAME_PIECE_GIVEN>, <NAME_PIECE> ]<br />
Given name or earned name. Different given names are separated by a comma.<br />
<br />
NAME_PIECE_NICKNAME: = {Size=1:30}<br />
[ <NAME_PIECE> | <NAME_PIECE_NICKNAME>, <NAME_PIECE> ]<br />
A descriptive or familiar name used in connection with one's proper name.<br />
<br />
NAME_PIECE_PREFIX: = {Size=1:30}<br />
[ <NAME_PIECE> | <NAME_PIECE_PREFIX>, <NAME_PIECE> ]<br />
Non indexing name piece that appears preceding the given name and surname parts. <br />
Different name prefix parts are separated by a comma. For example : <br />
Lt. Cmndr. Joseph /Allen/ jr.<br />
In this example Lt. Cmndr. is considered as the name prefix portion.<br />
<br />
NAME_PIECE_SUFFIX: = {Size=1:30}<br />
[ <NAME_PIECE> | <NAME_PIECE_SUFFIX>, <NAME_PIECE> ]<br />
Non-indexing name piece that appears after the given name and surname parts. <br />
Different name suffix parts are separated by a comma.<br />
For example :<br />
Lt. Cmndr. Joseph /Allen/ jr.<br />
In this example jr. is considered as the name suffix portion.<br />
<br />
NAME_PIECE_SURNAME: = {Size=1:120}<br />
[ <NAME_PIECE> | <NAME_PIECE_SURNAME>, <NAME_PIECE> ]<br />
Surname or family name. Different surnames are separated by a comma.<br />
<br />
NAME_PIECE_SURNAME_PREFIX: = {Size=1:30}<br />
[ <NAME_PIECE> | <NAME_PIECE_SURNAME_PREFIX>, <NAME_PIECE> ]<br />
Surname prefix or article used in a family name. Different surname articles are separated by a comma, <br />
for example in the name "de la Cruz", this value would be "de, la". <br />
<br />
Examples of NAME_PERSONAL:<br />
William Lee (given name only or surname not known)<br />
/Parry/ (surname only)<br />
William Lee /Parry/<br />
William Lee /Mac Parry/ (both parts (Mac and Parry) are surname parts<br />
William /Lee/ Parry (surname imbedded in the name string)<br />
William Lee /Pa.../ <br />
<br />
# GEDCOM has support for multiple surnames. They are separated by commas in the value of the SURN tag. No such provision is there for the NAME tag, so leaving the commas there is arguably not permitted by GEDCOM. Hence, SURN should contain all surnames, seperated by a comma.<br />
# PhpGedview has an extension to the name field that otherwise is not supported, should we follow it?: <br />
:1 NAME Cándida /Sánchez de la Torre/<br />
:2 GIVN Cándida<br />
:2 SURN Sánchez, Torre<br />
<br />
==Suggested workflow for export from Gramps==<br />
# all surnames are given to the SURN field divided by comma's<br />
# name field corresponds to the '''Formatted Name''' as seen in Gramps, with slashes (/) around the surnames<br />
# title is exported to NPFX <br />
# primary surname prefix and suffix go to SPFX, NSFX.<br />
<br />
As a consequence, a lot of information is lost on Gedcom export (callname, which is the primary name, connector), but all of the surname _is_ present in the NAME field.<br />
<br />
==Suggested workflow for import from Gramps== <br />
# all surnames in SURN (divided by comma's) are an entry in the surname list of Gramps<br />
# NAME field is parsed identifying the surname piece. All before a name goes to prefix of the surname behind it, what comes at the end goes to suffix of the last surname. If SPFX, NSFX is given, the surname that corresponds with that in name is set primary name, and prefix/suffix updated as needed<br />
# if primary surname cannot be identified, the first one is set primary.<br />
<br />
<br />
= User Interface = <br />
<br />
== Present surname use ==<br />
Surname now appears in ''display'' as and in ''sort as'' and in the preferences for name. The meaning of surname in those context would become the complete compound surname. If needed an extra format can be added: 'primary name'? This is to investigate further...<br />
<br />
== Name Editor ==<br />
<br />
The name editor must be reworked. Most important is that the new facilities for compound names do not slow down data entry of normal common surnames (that is eg German, English). So no listview is given for the list of compound names, instead the primary surname is fully shown with all fields, and a list is shown under it in those cases that a compound name is present or wanted. To work out further...<br />
<br />
Add buttons: obtain surnames from father, mother, child. On clicking these the surname list is added with those of the father, mother, child (no intelligent merging done). The father side is checked in case of father, mother side in case mother.<br />
<br />
When a person is selected in the person view, and add person is clicked, the surname list is generated with that of the selected person.<br />
<br />
Do we allow copy/paste of surname? For that we need a list where we can copy from/to. This will depend on the final design of the editor. Surname will be an object, so adding copy/paste is straightforward.<br />
<br />
== Compound Name Parser Tool ==<br />
A tool is written than can parse the first primary surname, and split it up in surname parts. This is to do the conversion from 3.2 to 3.3. The tool might also provide for the use-case of storing surname in given name, so parsing given name to add surnames to the surname list.<br />
<br />
= Upgrade =<br />
<br />
Upgrade from 3.2 to 3.3 database should be straightforward, with the exception of the disappearance of patronymic. <br />
<br />
# In 3.2 there is one surname, prefix, suffix, so this becomes the first (and primary) surname<br />
# if patronymic is given, there are the following possibilities<br />
## patronymic given, no surname. Patronymic becomes the first surname in the surname list, it is primary, and patronymic<br />
## patronymic is given and equal to surname. This reduces to the case above. <br />
## patronymic is given, surname is given, and they are not equal. This is a wrong use of the user or a user using patronymic as part of a compound surname. We always assume the last. The surname becomes the first surname and is primary. The patronym becomes the second surname and is set patronymic.<br />
<br />
<br />
= References =<br />
<br />
* [[Names Discussion]]<br />
* Starting discussion: [http://gramps.1791082.n4.nabble.com/compound-surnames-portuguese-td1814349.html#a1814349]<br />
* Discussion: [http://gramps.1791082.n4.nabble.com/Proposals-for-additional-name-fields-td1805382.html]<br />
* bug tickets: {{bug|3161}}, {{bug|4598}}<br />
<br />
[[Category:GEPS|A]]</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Template:Gramps_translations&diff=25063Template:Gramps translations2011-01-03T18:21:22Z<p>Fsmunoz: Added full name to Fsmunoz</p>
<hr />
<div><noinclude>A list of the languages in which GRAMPS has been translated, along with some additional information used during release cycles and contact information. <br />
<br />
For enabling, a language code must be set on ''configure.in'' file into ''ALL_LINGUAS'' section.<br />
<br />
[[Translating GRAMPS|Help translate GRAMPS to other languages]] or to improve existing translations.<br />
<br />
for file in *.po; do echo -n "${file} "; ./check_po -s ${file} | grep "Localized at"; done<br />
<!--<br />
...if between 0% and 59%, use the colour #ffa0a0<br />
...if between 60% and 79%, use the colour #ffd0d0<br />
...if between 80% and 89%, use the colour #fff0f0<br />
...if between 90% and 98%, use the colour #e0ffe0<br />
...if 99%, translation=english, use the colour #a0ffa0<br />
...if at exactly 100%, use the colour #a0ffa0<br />
--><br />
</noinclude>{| style="border: 1px #aaa solid; border-collapse:collapse; margin: 1em 1em 1em 1em;" border="1" align="left"<br />
! [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO-639-1]<br />
! Language<br />
! Contact<br />
! Coverage<br>gramps30; 3.0.4<br>2008-12-06<br />
! Coverage<br>gramps31; 3.1.4-SVN<br>2010-01-15<br />
! Coverage<br>gramps32; 3.2.6<br>2010-12-16<br />
! Coverage<br>trunk<br>2010-11-20<br />
! Notes<br />
|-<br />
| ar<br />
| Arabic<br />
| '''[[Translating_GRAMPS|unknown]]'''<br />
|align="right" bgcolor="#ffa0a0"| ?<br />
|align="right" bgcolor="#ffd0d0"| 51%<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/ar.po 10% (not enabled)]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/ar.po 10% (not enabled)]<br />
| see [http://sourceforge.net/mailarchive/message.php?msg_id=13026041 mailing-list]<br />
|-<br />
| bg<br />
| Bulgarian<br />
| [[User:borilg|Boril Gourinov]]<br />
|align="right" bgcolor="#ffd0d0"| 78%<br />
|align="right" bgcolor="#fff0f0"| 88%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 90%<br />
|-<br />
| br<br />
| Breton<br />
| '''[[Translating_GRAMPS|unknown]]'''<br />
|<br />
|<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/br.po 4% (not enabled)]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/br.po 4% (not enabled)]<br />
|-<br />
| ca<br />
| Catalan<br />
| Joan Creus (jcreus)<br />
|align="right" bgcolor="#fff0f0"| 80%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 90%<br />
|-<br />
| cs<br />
| Czech<br />
| Zdeněk Hataš (matlas)<br />
|align="right" bgcolor="#e0ffe0"| 97%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#fff0f0"| 85%<br />
|align="right" bgcolor="#fff0f0"| 86%<br />
|-<br />
| da<br />
| Danish<br />
| Morten Bo Johansen<br />
|align="right" bgcolor="#e0ffe0"| 89%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#fff0f0"| 86%<br />
|align="right" bgcolor="#ffd0d0"| 79%<br />
|-<br />
| de<br />
| German<br />
| [[User:Leonhaeuser|Mirko Leonhäuser]]<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 95%<br />
|-<br />
| en<br />
| English<br />
| n/a<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|-<br />
| eo<br />
| Esperanto<br />
| '''[[Translating_GRAMPS|unknown]]'''<br />
|align="right" bgcolor="#ffd0d0"| 76%<br />
|align="right" bgcolor="#ffa0a0"| 14%<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/eo.po 12% (not enabled)]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/eo.po 11% (not enabled)]<br />
|-<br />
| es<br />
| Spanish<br />
| Julio Sánchez (jsanchez)<br />
|align="right" bgcolor="#e0ffe0"| 94%<br />
|align="right" bgcolor="#e0ffe0"| 93%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 91%<br />
|[http://www.gramps-project.org/bugs/view.php?id=4185 Kinship report (Relationhips)]<br />
|-<br />
| fi<br />
| Finnish<br />
| Eero Tamminen - Janne Kovesjärvi<br />
|align="right" bgcolor="#e0ffe0"| 97%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#fff0f0"| 83%<br />
|align="right" bgcolor="#ffd0d0"| 76%<br />
|-<br />
| fr<br />
| French<br />
| [[User:Romjerome|Jérôme Rapinat]]<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 98%<br />
|-<br />
| he<br />
| Hebrew<br />
| igal_shapira<br />
|align="right" bgcolor="#ffa0a0"| -<br />
|align="right" bgcolor="#ffd0d0"| 35%<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/he.po 67%]<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/he.po 62%]<br />
|[http://www.gramps-project.org/bugs/view.php?id=2962 bug report #2962]<br />
|-<br />
| hr<br />
| Croatian<br />
| [[User:Zaboravni|Josip]]<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 98%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 90%<br />
|-<br />
| hu<br />
| Hungarian<br />
| Arpad Horvath<br />
|align="right" bgcolor="#fff0f0"| 87%<br />
|align="right" bgcolor="#ffd0d0"| 58%<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/hu.po 50%]<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/hu.po 45%]<br />
|-<br />
| it<br />
| Italian<br />
| Luigi Toscano (ltosky)<br />
|align="right" bgcolor="#e0ffe0"| 92%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 90%<br />
|[http://www.gramps-project.org/bugs/view.php?id=4185 Kinship report (Relationhips)]<br />
|-<br />
| lt<br />
| Lithuanian<br />
| Arturas Sleinius (asleinius)<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#fff0f0"| 89%<br />
|[http://gramps.1791082.n4.nabble.com/Attention-Translators-New-month-strings-in-DateDisplayers-td1805671.html month names]<br />
|-<br />
| mk<br />
| Macedonian<br />
| [[User:Aleksandarsi|Alexsandar Silovski]]<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#ffd0d0"| 50%<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/mk.po 42% (not enabled)]<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/mk.po 39% (not enabled)]<br />
|-<br />
| nb<br />
| Norwegian Bokmål<br />
| [[User:Espenbe|Espen Berg]]<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 93%<br />
|-<br />
| nn<br />
| Norwegian Nynorsk<br />
| Sigmund Lorentsen<br />
|align="right" bgcolor="#ffa0a0"| ?<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 91%<br />
|-<br />
| nl<br />
| Dutch<br />
| [[User:erikdr|Erik Ranst]]<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 91%<br />
|-<br />
| pl<br />
| Polish<br />
| [[User:Yenidai|Łukasz Rymarczyk]]<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99% <br />
|align="right" bgcolor="#a0ffa0"| 99% <br />
|-<br />
| pt_BR<br />
| Portuguese (Brazil)<br />
| Luiz Gonzaga dos Santos Filho, [[user:lcc|lcc]]<br />
|align="right" bgcolor="#fff0f0"| 88%<br />
|align="right" bgcolor="#ffd0d0"| 61%<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/pt_BR.po 52%]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/pt_BR.po 48%]<br />
|[http://www.gramps-project.org/bugs/view.php?id=4185 Kinship report (Relationhips)]<br />
|-<br />
| pt_PT<br />
| Portuguese (Portugal)<br />
| [[user:Fsmunoz|Frederico Muñoz]]<br />
|<br />
|<br />
|<br />
|align="right" bgcolor="#fff0f0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/pt_PT.po 80%]<br />
|[http://www.gramps-project.org/bugs/view.php?id=4185 Kinship report (Relationhips)]<br />
|-<br />
| ro<br />
| Romanian<br />
| '''[[Translating_GRAMPS|unknown]]'''<br />
|align="right" bgcolor="#ffd0d0"| 62%<br />
|align="right" bgcolor="#ffa0a0"| 7%<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/ro.po 6% (not enabled)]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/ro.po 6% (not enabled)]<br />
|-<br />
| ru<br />
| Russian<br />
| Yevgeny Zegzda, Konstantin Dorichev (kdorichev), Andrew I Baznikin<br />
|align="right" bgcolor="#e0ffe0"| 95%<br />
|align="right" bgcolor="#ffd0d0"| 72%<br />
|align="right" bgcolor="#fff0f0"| 82%<br />
|align="right" bgcolor="#fff0f0"| 88%<br />
|-<br />
| sk<br />
| Slovak<br />
| Lubo Vasko<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 90%<br />
|-<br />
| sl<br />
| Slovenian<br />
| Bernard Banko<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#ffd0d0"| 78%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 95%<br />
|-<br />
| sq<br />
| Albanian<br />
| '''[[Translating_GRAMPS|unknown]]'''<br />
|align="right" bgcolor="#ffa0a0"| ?<br />
|align="right" bgcolor="#ffd0d0"| 79%<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/sq.po 66%]<br />
|align="right" bgcolor="#ffd0d0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/sq.po 61%]<br />
|-<br />
| sr<br />
| Serbian<br />
| VPeric<br />
|align="right" bgcolor="#ffa0a0"| 6%<br />
|align="right" bgcolor="#ffa0a0"| ?<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/sr.po 5% (not enabled)]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/sr.po 5% (not enabled)]<br />
| see [http://www.gramps-project.org/bugs/view.php?id=2375 bug report #2375]<br />
|-<br />
| sv<br />
| Swedish<br />
| [[User:PeterL|Peter Landgren]]<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#a0ffa0"| 100%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 95%<br />
|-<br />
| tr<br />
| Turkish<br />
| '''[[Translating_GRAMPS|unknown]]'''<br />
|align="right" bgcolor="#ffa0a0"| 44%<br />
|align="right" bgcolor="#ffa0a0"| 7%<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps32/po/tr.po 6% (not enabled)]<br />
|align="right" bgcolor="#ffa0a0"| [http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/tr.po 6% (not enabled)]<br />
|-<br />
| zh_CN<br />
| Chinese<br />
| [[user:Honeyword|Honeyword]]<br />
|align="right" bgcolor="#ffa0a0"| 37%<br />
|align="right" bgcolor="#fff0f0"| 86%<br />
|align="right" bgcolor="#a0ffa0"| 99%<br />
|align="right" bgcolor="#e0ffe0"| 91%<br />
| [http://www.gramps-project.org/bugs/view.php?id=4400 lunisolar calendar support ?]<br />
|} <br />
<br clear=all><br />
{| style="border: 1px #aaa solid; border-collapse:collapse; margin: 1em 1em 1em 1em;" border="1" align="left"<br />
! Custom<br />
! Type<br />
! Contact<br />
! Coverage<br>Gramps 2.2.6<br />
! Coverage<br>Gramps 3.1.3<br />
! Coverage<br>(trunk)<br />
! Notes<br />
|-<br />
| [http://gramps-project.org/wiki/index.php?title=Image:Animal.po.gz Animal Pedigree]<br />
| [[Animal pedigree]]<br />
| unknown<br />
|align="right" bgcolor="#a0ffa0"| [http://gramps-project.org/wiki/index.php?title=Image:Gramps_animal_2_2_6.po.gz 100%]<br />
|align="right" bgcolor="#a0ffa0"| [http://gramps-project.org/wiki/index.php?title=Image:Animal.po.gz 99%]<br />
|align="right" bgcolor="#ffa0a0"| 0%<br />
|English(US) sub-translation that makes using GRAMPS far more intuitive when dealing with animals.<br />
|-<br />
| [http://www.gramps-project.org/bugs/view.php?id=3346 Same gender]<br />
| Same gender/sex<br />
| unknown<br />
|align="right"| -<br />
|align="right" bgcolor="#a0ffa0"| [http://www.gramps-project.org/bugs/view.php?id=3346 100%]<br />
|align="right" bgcolor="#ffa0a0"| 0%<br />
|English(US) sub-translation that makes using GRAMPS far more intuitive when dealing with same gender family.<br />
|} <br />
<br clear=all><br />
<noinclude><br />
<br />
[[Category:Translators/Categories]][[Category:Developers/General]]<br />
</noinclude></div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=User:Fsmunoz/Tradu%C3%A7%C3%A3o_Portuguesa&diff=25054User:Fsmunoz/Tradução Portuguesa2011-01-03T13:10:55Z<p>Fsmunoz: </p>
<hr />
<div>== Objectivo ==<br />
<br />
Esta página destina-se a documentar linhas orientadores, regras e recursos que auxiliem no esforço de tradução do Gramps em português.<br />
<br />
=== Qual português? ===<br />
<br />
O objectivo (ou objetivo :D) é criar uma base sólida que sirva de igual modo as variantes Europeia e Brasileira da língua (pt_PT e pt_BR), evitando tanto quanto possível a divergência por motivos que sejam completamente desnecessários. Tal não significa que não devam existir versões próprias que usem termos e construções próprias de cada variante, apenas que tais adaptações sejam feitas em cima de um tronco comum.<br />
<br />
=== Motivação de um tronco comum ===<br />
<br />
Quando duas pessoas diferentes traduzem uma mesma frase é quase inevitável que o façam de forma ligeiramente diferente, mesmo que falem exactamente a mesma variante. Um exemplo: a frase "I would like to participate in the Portuguese translation effort" pode ser traduzida de variadas formas:<br />
<br />
* Gostaria de participar no esforço de tradução para língua portuguesa<br />
* Gostava de poder auxiliar no esforço de tradução para português<br />
* Ficaria feliz em poder ajudar na tradução para português<br />
* etc.<br />
<br />
Nenhuma destas frases é, em sentido estrito, errada, e todas transmitem a mesma ideia. O problema de não coordenar traduções entre pt_PT e pt_BR é que muitas vezes, ao desconsiderar a tradução existente, introduzem-se alterações que não sendo erradas são desnecessárias.<br />
<br />
Por outro lado existe um vocabulário próprio e quase técnico de genealogia que convém analisar. Muitas vezes o desconhecimento dos termos em uso pela comunidade de genealogistas pode levar à introdução de termos que são uma tradução literal do inglês quando já existem vocábulos próprios em utilização.<br />
<br />
=== Limites ===<br />
<br />
Existem no entanto termos e construções que são próprias de cada variante e que necessitam como tal de serem considerados. Seria contra-producente tentar criar uma tradução única que não fosse do agrado de nenhuma das partes. Exemplos óbvios são palavras com grafia diferente ("mídia"/"média") ou significado diferente ("apelido"). Para todos esteas casos é necessário considerar a especificidade de cada variante.<br />
<br />
Tanto quanto possível este tipo de alterações pode ser feito de forma quase automática, identificando para isso quais os termos em questão. A única excepção são as construções gramaticais diferentes. Estas devem, no entanto, ser reduzidas ao mínimo, adoptando construções que sejam o mais neutras possíveis.<br />
<br />
<br />
== Linhas orientadoras ==<br />
<br />
Na tradução por mim efectuada, e que foi baseada na versão pt_BR existente, tentei seguir as seguintes linhas orientadoras (nem sempre com sucesso)<br />
<br />
;Utilização do último Acordo Ortográfico<br />
:Apesar de esta página não utilizar a grafia do último Acordo Ortográfico (nem de eu o fazer em comunicação pessoal) a tradução utiliza-o. Onde nesta página se lê "objectivo" e "adopção" na tradução efectuada estaria "objetivo" e "adoção". Esta decisão tem maior impacto na versão pt_PT dado o maior número de consoantes mudas na variante portuguesa da língua, mas independentemente do meu gosto pessoal pelo referido Acordo ele é uma realidade e a sua utilização reduz substancialmente este tipo de pequenas diferenças.<br />
<br />
;Utilização de construções gramaticais o mais neutras possíveis<br />
:Com isto quero dizer que sempre que uma determinada construção gramatical pode ser feita de uma forma mais neutra para ambas as variantes foi essa a construção utilizada. Isto inclui casos onde determinada forma é mais típica de uma variante mas também correcta na outra. Um exemplo é a manutenção da utilização do gerúndio na esmagadora maioria dos casos ("analisando" vs. "a analisar"), que sendo regra no Brasil não é de forma alguma rara ou errada em Portugal.<br />
<br />
;Melhoria da consistência interna da tradução<br />
:A própria versão original em inglês tem inconsistências várias, fruto de ser feita por pessoas diferentes em alturas diferentes. Os tempos verbais para uma mesma frase são diferentes, a utilização de pontuação não é consistentes, etc. Tanto quanto possível a tradução em português deve tentar evitar uma tradução literal que introduza este tipo de inconsistências e utilizar contruções gramaticais e vocabulário idêntico para frases com sentido idêntico.<br />
<br />
;Alinhamento com as traduções em línguas novilatinas<br />
:Existem dificuldades na passagem para português de algumas frases e expressões em inglês que se devem à origem diferente das línguas. Como tal faz sentido olhar para as traduções existentes em línguas de origem latina (em especial o espanhol, mas também o francês e italiano) de forma a analisar as soluções encontradas. Muitas vezes torna-se mais simples utilizar soluções idênticas que sejam adequadas.<br />
<br />
;Utilização de vocabulário técnico de genealogia em português<br />
:A genealogia, tanto em Portugal como no Brasil, não apareceu hoje ou ontem: existe há séculos, tal como nos restantes países europeus, e utiliza termos e expressões específicos. Como tal é de evitar a utilização de traduções literais do inglês quando as mesmas têm já um vocábulo em português. De notar que este tipo de vocabulário é praticamente todo comum entre os genealogistas de Portugal e do Brasil dada a antiguidade da prática genealógica.<br />
<br />
== Vocabulário ==<br />
<br />
<tabela com as traduções de termos genealógicos, etc><br />
<br />
== Diferenças ==<br />
<br />
<tabela com diferenças entre as variantes que têm obrigatóriamente de ser <br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Inglês !! pt_PT !! pt_BR !! class="unsortable" | Obs.<br />
|-<br />
| media || média || mídia ||<br />
|-<br />
| surname || apelido || sobrenome || "apelido" no Brasil significa o que "alcunha" ou "apodo" significam em Portugal. Considerar no entanto "nome de família"<br />
|-<br />
| || || || <br />
|-<br />
|}<br />
<br />
== Recursos externos ==<br />
<br />
[http://ccc.com.pt/genea/dicionario.htm Dicionário Genealógico]<br />
<br />
[http://www.asbrap.org.br/publicac/manual/vocabulario.htm Vocabulário Técnico Genealógico] (semelhante ao anterior, diferente formatação)</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=User:Fsmunoz/Tradu%C3%A7%C3%A3o_Portuguesa&diff=25053User:Fsmunoz/Tradução Portuguesa2011-01-03T12:50:59Z<p>Fsmunoz: </p>
<hr />
<div>== Objectivo ==<br />
<br />
Esta página destina-se a documentar linhas orientadores, regras e recursos que auxiliem no esforço de tradução do Gramps em português.<br />
<br />
=== Qual português? ===<br />
<br />
O objectivo (ou objetivo :D) é criar uma base sólida que sirva de igual modo as variantes Europeia e Brasileira da língua (pt_PT e pt_BR), evitando tanto quanto possível a divergência por motivos que sejam completamente desnecessários. Tal não significa que não devam existir versões próprias que usem termos e construções próprias de cada variante, apenas que tais adaptações sejam feitas em cima de um tronco comum.<br />
<br />
=== Motivação de um tronco comum ===<br />
<br />
Quando duas pessoas diferentes traduzem uma mesma frase é quase inevitável que o façam de forma ligeiramente diferente, mesmo que falem exactamente a mesma variante. Um exemplo: a frase "I would like to participate in the Portuguese translation effort" pode ser traduzida de variadas formas:<br />
<br />
* Gostaria de participar no esforço de tradução para língua portuguesa<br />
* Gostava de poder auxiliar no esforço de tradução para português<br />
* Ficaria feliz em poder ajudar na tradução para português<br />
* etc.<br />
<br />
Nenhuma destas frases é, em sentido estrito, errada, e todas transmitem a mesma ideia. O problema de não coordenar traduções entre pt_PT e pt_BR é que muitas vezes, ao desconsiderar a tradução existente, introduzem-se alterações que não sendo erradas são desnecessárias.<br />
<br />
Por outro lado existe um vocabulário próprio e quase técnico de genealogia que convém analisar. Muitas vezes o desconhecimento dos termos em uso pela comunidade de genealogistas pode levar à introdução de termos que são uma tradução literal do inglês quando já existem vocábulos próprios em utilização.<br />
<br />
=== Limites ===<br />
<br />
Existem no entanto termos e construções que são próprias de cada variante e que necessitam como tal de serem considerados. Seria contra-producente tentar criar uma tradução única que não fosse do agrado de nenhuma das partes. Exemplos óbvios são palavras com grafia diferente ("mídia"/"média") ou significado diferente ("apelido"). Para todos esteas casos é necessário considerar a especificidade de cada variante.<br />
<br />
Tanto quanto possível este tipo de alterações pode ser feito de forma quase automática, identificando para isso quais os termos em questão. A única excepção são as construções gramaticais diferentes. Estas devem, no entanto, ser reduzidas ao mínimo, adoptando construções que sejam o mais neutras possíveis.<br />
<br />
<br />
== Linhas orientadoras ==<br />
<br />
Na tradução por mim efectuada, e que foi baseada na versão pt_BR existente, tentei seguir as seguintes linhas orientadoras (nem sempre com sucesso)<br />
<br />
;Utilização do último Acordo Ortográfico<br />
:Apesar de esta página não utilizar a grafia do último Acordo Ortográfico (nem de eu o fazer em comunicação pessoal) a tradução utiliza-o. Onde nesta página se lê "objectivo" e "adopção" na tradução efectuada estaria "objetivo" e "adoção". Esta decisão tem maior impacto na versão pt_PT dado o maior número de consoantes mudas na variante portuguesa da língua, mas independentemente do meu gosto pessoal pelo referido Acordo ele é uma realidade e a sua utilização reduz substancialmente este tipo de pequenas diferenças.<br />
<br />
;Utilização de construções gramaticais o mais neutras possíveis<br />
:Com isto quero dizer que sempre que uma determinada construção gramatical pode ser feita de uma forma mais neutra para ambas as variantes foi essa a construção utilizada. Isto inclui casos onde determinada forma é mais típica de uma variante mas também correcta na outra. Um exemplo é a manutenção da utilização do gerúndio na esmagadora maioria dos casos ("analisando" vs. "a analisar"), que sendo regra no Brasil não é de forma alguma rara ou errada em Portugal.<br />
<br />
;Melhoria da consistência interna da tradução<br />
:A própria versão original em inglês tem inconsistências várias, fruto de ser feita por pessoas diferentes em alturas diferentes. Os tempos verbais para uma mesma frase são diferentes, a utilização de pontuação não é consistentes, etc. Tanto quanto possível a tradução em português deve tentar evitar uma tradução literal que introduza este tipo de inconsistências e utilizar contruções gramaticais e vocabulário idêntico para frases com sentido idêntico.<br />
<br />
;Alinhamento com as traduções em línguas novilatinas<br />
:Existem dificuldades na passagem para português de algumas frases e expressões em inglês que se devem à origem diferente das línguas. Como tal faz sentido olhar para as traduções existentes em línguas de origem latina (em especial o espanhol, mas também o francês e italiano) de forma a analisar as soluções encontradas. Muitas vezes torna-se mais simples utilizar soluções idênticas que sejam adequadas.<br />
<br />
;Utilização de vocabulário técnico de genealogia em português<br />
:A genealogia, tanto em Portugal como no Brasil, não apareceu hoje ou ontem: existe há séculos, tal como nos restantes países europeus, e utiliza termos e expressões específicos. Como tal é de evitar a utilização de traduções literais do inglês quando as mesmas têm já um vocábulo em português. De notar que este tipo de vocabulário é praticamente todo comum entre os genealogistas de Portugal e do Brasil dada a antiguidade da prática genealógica.<br />
<br />
== Vocabulário ==<br />
<br />
<tabela com as traduções de termos genealógicos, etc><br />
<br />
== Diferenças ==<br />
<br />
<tabela com diferenças entre as variantes que têm obrigatóriamente de ser <br />
<br />
== Recursos externos ==<br />
<br />
[http://ccc.com.pt/genea/dicionario.htm Dicionário Genealógico]<br />
<br />
[http://www.asbrap.org.br/publicac/manual/vocabulario.htm Vocabulário Técnico Genealógico] (semelhante ao anterior, diferente formatação)</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=User:Fsmunoz/Tradu%C3%A7%C3%A3o_Portuguesa&diff=25052User:Fsmunoz/Tradução Portuguesa2011-01-03T12:08:11Z<p>Fsmunoz: Página inicial</p>
<hr />
<div>== Objectivo ==<br />
<br />
Esta página destina-se a documentar linhas orientadores, regras e recursos que auxiliem no esforço de tradução do Gramps em português.<br />
<br />
=== Qual português? ===<br />
<br />
O objectivo (ou objetivo :D) é criar uma base sólida que sirva de igual modo as variantes Europeia e Brasileira da língua (pt_PT e pt_BR), evitando tanto quanto possível a divergência por motivos que sejam completamente desnecessários. Tal não significa que não devam existir versões próprias que usem termos e construções próprias de cada variante, apenas que tais adaptações sejam feitas em cima de um tronco comum.<br />
<br />
=== Motivação de um tronco comum ===<br />
<br />
Quando duas pessoas diferentes traduzem uma mesma frase é quase inevitável que o façam de forma ligeiramente diferente, mesmo que falem exactamente a mesma variante. Um exemplo: a frase "I would like to participate in the Portuguese translation effort" pode ser traduzida de variadas formas:<br />
<br />
* Gostaria de participar no esforço de tradução para língua portuguesa<br />
* Gostava de poder auxiliar no esforço de tradução para português<br />
* Ficaria feliz em poder ajudar na tradução para português<br />
* etc.<br />
<br />
Nenhuma destas frases é, em sentido estrito, errada, e todas transmitem a mesma ideia. O problema de não coordenar traduções entre pt_PT e pt_BR é que muitas vezes, ao desconsiderar a tradução existente, introduzem-se alterações que não sendo erradas são desnecessárias.<br />
<br />
Por outro lado existe um vocabulário próprio e quase técnico de genealogia que convém analisar. Muitas vezes o desconhecimento dos termos em uso pela comunidade de genealogistas pode levar à introdução de termos que são uma tradução literal do inglês quando já existem vocábulos próprios em utilização.<br />
<br />
=== Limites ===<br />
<br />
Existem no entanto termos e construções que são próprias de cada variante e que necessitam como tal de serem considerados. Seria contra-producente tentar criar uma tradução única que não fosse do agrado de nenhuma das partes. Exemplos óbvios são palavras com grafia diferente ("mídia"/"média") ou significado diferente ("apelido"). Para todos esteas casos é necessário considerar a especificidade de cada variante.<br />
<br />
Tanto quanto possível este tipo de alterações pode ser feito de forma quase automática, identificando para isso quais os termos em questão. A única excepção são as construções gramaticais diferentes. Estas devem, no entanto, ser reduzidas ao mínimo, adoptando construções que sejam o mais neutras possíveis.<br />
<br />
<br />
== Linhas orientadoras ==</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Organise_your_files&diff=19000Organise your files2009-09-20T17:22:47Z<p>Fsmunoz: Family-based approach</p>
<hr />
<div>[[Category:Genealogy]]<br />
{{languages|Organise your files}}<br />
<br />
= Jerry's system =<br />
Here is my method of directory and file organization.<br />
<br />
* '''/srv''' - I store all my server files in /srv, including WWW and Samba. This is the [http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard standard UNIX directory] for "Site-specific data which is served by the system."<br />
<br />
Then I place all my genealogy related files in a directory call ./Genealogy. The exact path may depend on how you are set up. Here are three different possibilities.<br />
<br />
/srv/Genealogy/ <br />
/srv/Samba/Genealogy/ - If you use a samba file share.<br />
/srv/Samba/Family/Genealogy/ - This has the /Genealogy in a file share of /Family. <br />
<br />
''This is the structure of ./Genealogy:''<br />
<br />
Basically there are three main areas. Books or publishing. Documents, which are the Media storage area. Gramps.<br />
<br />
* ''./Books_Published/'' - All books that I have published, such as "Perkins Family History".<br />
<br />
* ''./Books_In_Process/'' - Current book that I am working on.<br />
<br />
* ''./Doc/'' - This is the big one where I store all the Media files. Nothing goes in here till it is put into Gramps Media. See the ./Need_to_Process directory below.<br />
<br />
'''File Names''': <br />
<br />
I am big on "Noun Naming". This makes it quick and easy to find documents. Hence for the ./Census directory I use the file name format of <STATE>-<COUNTY>-<CITY><YEAR>-<ENUMERATION>-<PAGE>.jpeg For the Media Title I use Census <COUNTRY>, STATE>, <CITY / TOWNSHIP>, <YEAR ENUMERATION>, p. <PAGE> - <FAMILY>. The Source Tile is the same, except without the , <YEAR ENUMERATION>, p. <PAGE> - <FAMILY>.<br />
<br />
This makes it quick and easy to find and cleanup errors. Periodically I do a sort, then quickly look for errors. This includes the path field in the Media.<br />
<br />
* ''./Doc/Book_<BOOK NAME>/'' I have stored documents such as birth certificates, in a three ring binder. These are enclosed in acid free clear sleeves. The "<BOOK NAME>" is the name of the binder. Or you could create a directory for each book.<br />
<br />
* ''./Doc/Book_<BOOK NAME>/001-<TITLE>.jpeg'' These are the scans from the book. The first three digits are the page number of the acid free sleeve. Then a title (<TITLE>). This title is the same as I use for the Media title. Hence a path of ./Doc/Book_1/031-Birth_Record_Perkins_Gerald.png has a Media Title of "Birth Record Perkins, Gerald Dana"<br />
<br />
* ''./Doc/Census/'' For a path of ./Doc/Census/california-humboldt-south_fork_township-1920-69-1b.jpeg, the Media title is "Census USA, California, Humboldt, South Fork Township 1920 69 p. 1B", then the Source Title would be "Census USA, California, Humboldt, South Fork Township 1920".<br />
<br />
* ''./Doc/Head_Shot/'' Where I keep an individuals head shot. These are placed in People > Person > Gallery. Hence their picture shows up.<br />
<br />
* ''./Doc/Indiana_Marriage_Collection_1800-1941/'' <br />
<br />
* ''./Doc/Media_yyyy/'' This is kind of my general catch all. I know, not good. It started to be so large that I started a new one every year. Slowly I have moved some to there proper directories.<br />
<br />
* ''./Doc/Military/'' Example "Registration_Perkins_C_Ray.jpeg"<br />
<br />
* ''./Doc/Naturalization/'' Example "Helwig_Otto.jpeg"<br />
<br />
* ''./Doc/Object/'' These are photos of objects such as "Military_POW_Tag_Helwig_Charles.jpeg"<br />
<br />
* ''./Doc/Ship_Manifest/'' I have been working on the format here. This is a current example sm-philadelphia_rhynland-m-1901-06-16.jpeg. Where philadelphia is the port of entry. And rhynland is the ship. i = Immigration document, m = manifest.<br />
<br />
* ''./Gramps/'' The home of Gramps.<br />
<br />
* ''./Gramps-yyy-mm-dd/'' If I try something that may make a mess of Gramps, I create a backup copy.<br />
<br />
* ''./Miscellaneous/'' Currently store blank Census forms and the like.<br />
<br />
* ''./Need_To_Process/'' Any new files, photos, etc that I need to process into Gramps. Kind of a holding area.<br />
<br />
= Duncan's system =<br />
<br />
I'm still working this one out but here goes... I have an NTFS partition which I can access from both Windows XP and Ubuntu Linux, that's where I keep all my genealogy files. Because my main computer for doing genealogy work switches between two machines every now and then I name the directory after when I move it to that system. At the moment it's called ''Database_in_2008-06-20'', which I won't type every time, consider './' to mean 'the main directory'.<br />
<br />
./Backups/ - has GRAMPS XML files as backups, I do this about once a month and after any large change.<br />
./Dropbox/ - has anything I haven't dealt with yet (it's quite full!)<br />
./Events/$EventNames/ - has media files which are primarily related to an event.<br />
./Individuals/$Surnames/ - has images primarily related to an individual. The files are sorted after the persons (birth) surname.<br />
./Individuals_icons/ - has passport sized images use for generating reports<br />
./Places/$Country/ - has files primarily related to a specific place. I will start subdirectories by country.<br />
./Rapports/$Surname - has some rapports I've sent out.<br />
./Sources/$Source - has all sorts of files which contain direct information, scanned letters and so on... Sorted by the source's source.<br />
./2008-03-11_4.gramps - there are often quite a few of these backups which I go through and put a couple in the ./Backups/ directory and throw the others out.<br />
<br />
I don't think this system is so great so I'm working on improving it, see below.<br />
<br />
= Duncan's planned system =<br />
<br />
== The goal ==<br />
After researching for the [[Portable Filenames]] article I've decided to aim for a system designed to work on any computer made after 1994.<br />
<br />
Directory depth is limited to media plus 7 (limit of [http://en.wikipedia.org/wiki/ISO_9660 ISO 9660])<br />
media/2/3/4/5/6/7/file<br />
<br />
File and directory names are limited to<br />
a-z Lowercase alphabetical characters (see below)<br />
A-Z Uppercase alphabetical characters (see below)<br />
0-9 Numerals<br />
- Hyphens/ dashes (must not start a files name)<br />
_ Underscores<br />
all names have a combination of lower and uppercase letters so they don't change case<br />
<br />
File path lengths need to be limited to 256 characters (limit of [http://msdn.microsoft.com/en-us/library/aa365247.aspx Windows Path Size])<br />
Requires manual checking<br />
<br />
Indicating unsure or incomplete dates<br />
--1810ca--<br />
or<br />
--1810-09ca--<br />
or<br />
--1810before--<br />
or<br />
--1810-09-15before--<br />
or<br />
--1810-_-10--<br />
<br />
== Problems in progress ==<br />
* When I want to work on one family with a small portable computer?<br />
** all folders need to under the family name directory, for families under a dual name directory, children under their own family name.<br />
* What about a family portrait not from a known event?<br />
** I think it's best to regard pictures of groups as an event, maybe event=gathering<br />
<br />
== Directory tree ==<br />
<br />
The base directory is not shown. A name like Imported_2008-12-23 is recommended to record when the data was moved to this machine from some other machine.<br />
<br />
Directory naming rules:<br />
* Top directory is <upper case letter><lower case start of range>-<lower case end of range>, ie ''Aa-z'' for all the ''A''s or ''Sl-z'' for surnames starting with ''Sl'' through to ''Sz''. This may look like overkill but it is primarily to avoid directories with letters in only one case as these can change case without warning on older Windows systems, breaking file paths.<br />
* Start words in directory names with capitals so Windows file systems don't change the case.<br />
* Once a family starts (shared address, children or legal union) any common files go into a family directory (alphabetically sorted) ie: ''Jensen__Williams''<br />
<br />
<upper case letter><lower case start of range>-<lower case end of range>/<br />
<family name>/<br />
<record type>/<br />
<file><br />
or<br />
<given name(s)>/<br />
<file><br />
or<br />
<event type>/<br />
<file><br />
<br />
For example<br />
<br />
Ja-z/Jetson/Ind/Jetson__George/Sou/S--award--jetson--george--luna_city--2014--his_pilots_license--0562.jpg<br />
Ga-l/George__Spencer/Evt/Marriage/S--marriage--george__spencer--charles__diana--england_somewhere--1981--wedding_certificate--0065.png<br />
<br />
= Jerome's system =<br />
<br />
My Media objects use the same naming structure :<br />
<br />
ISO 8601 date_description.extension<br />
<br />
./Docs/ numerical sources (scanned certificates, papers, acts, hand written sources)<br />
./Identity/ passport sized images use for generating reports<br />
./Places/ (photos of gravestones, living places or address)<br />
./Other/ not in the first ... (videos, sounds, groups photos)<br />
<br />
I will not add subdirectories.<br />
Also, all objects are duplicated on an other support (backups and searchs) with my grandparents' surname :<br />
<br />
./Surname of the mother of my mother (maiden)<br />
./Surname of the father of my mother<br />
./Surname of the mother of my father (maiden)<br />
./Surname of the father of my father <br />
<br />
And I use attributes on my database (as marker). True, using relationships calculator should do the work but it is usefull for filtering and sharing data. <br />
Why attributes ? Adding this value (like a description) is not false ...<br />
They are and will still be my ancestors on (father or mother side) <br />
<br />
-- [[User:Romjerome|Romjerome]] 26 July 2008 (EDT)<br />
<br />
= Frederico's system =<br />
<br />
I'm converting my physical storage system from a ad-hoc solution based on a 2-ring binder with all the documents (organised by the Soza number) to a vertical filling system that is organised by manilla folders that contain all the relevant information for each family. The focus is thus less on the individual and more on the family. Using folders allow for a much easier way to aggregate all relevant documents (certificates, photos, research logs, etc) and also facilitates research since each folder is pretty much self-contained and can be easily retrieved when needed, and taken to the archives for investigation.<br />
<br />
With that in mind it makes some sense to mirror this physical approach when organising digital documents, especially since every document has both a physical copy and a digital one. I am experimenting with creating a directory for each family under a Sources folder (it could also be named Families, or any other name really), like this:<br />
<br />
./SMITH,John+BLACK,Mary<br />
./LEWIS,Edward+MCDONALD,Jane<br />
<br />
The contents follow the same rules as the physical archiving. Of note is the fact that each person is generally present in two different folder: as a son they are present in the folder of the parents, and as one of the members of a family they have their own folder. Documents related to pre-marriage events go into the parent's folder, and from the marriage onward to their own folder.<br />
<br />
Filenames follow more or less the examples given, e.g. BAP--John_Smith--1830.png.<br />
<br />
The advantages I can see so far are:<br />
<br />
* Consistency between physical archive and digital storage. It makes is easier to compare the completeness of both of them so they they are not our of sync.<br />
* Easy to access all documents that relate to a family. Since many documents have information that applies to more than one family member it makes sense.<br />
* Each directory can be archived and sent to someone else and all the relevant sources are contained therein.<br />
<br />
Some disadvantages:<br />
<br />
* Storing the birth certificates (or any pre-marriage information) of an individual not under his own folder but under the parents' folder can be a bit counter-intuitive in the beginning.<br />
* Since it is Family based (and not Individual based) documents that relate to an individual are split between two folders.<br />
* Sometimes one doesn't have information about the marital status of an individual, and when that is latter discovered files could have to be moved. An example would be the military record of an individual that doesn't contain information about his marriage, and since there is no other source that contains such an information it is not possible to create a Family directory. When latter that information surfaces those documents would have to be moved to the Family folder.<br />
<br />
= Your system? =</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Genetics&diff=18968Genetics2009-09-16T16:21:09Z<p>Fsmunoz: /* M-line research */</p>
<hr />
<div>{{languages}}<br />
Everybody following genealogy publications will have encountered the use of genetics in genealogy: hereditary diseases, genetic markers, ...<br />
<br />
Here we give an overview of what type of genetics data is important in genealogy.<br />
<br />
==Introduction==<br />
Humans have 23 pairs of chromosomes which form their DNA (deoxyribose nucleic acid). Each of us inherits one of each pair from one parent, and the other from the second parent. From the mother one inherits one cell of which these chromosomes form the nucleus. However, this cell also contains some genetic material which is not part of the human chromosome, called mitochondrial DNA (mtDNA), and also essential for our survival. A special role is given to the sex chromosome. For females this is a pair of X chromosomes, one from the mother, one from the father. For males however this pair consists of a X chromosome inhereted from the mother, and a Y chromosome, inhereted from the father. <br />
<br />
At each generation, 23 chromosomes are passed through to the children, constituted of material from the 23 chromosome pairs of the parents. Over time, mutations also happen, meaning that parts of the chromosome are not identical to the same parts on the DNA of the parents. Mutations that are not lethal are called variants. Some mutations happen fast, some slow, and some very slow. Should there be no mutation it would be impossible to tell how related people are one from the other. Fast mutations allow to distinguish family groups recently in time. Slow mutations allow to distinguish race groups up to ancient migration patterns, e.g. the saxon migration into Europe.<br />
<br />
===Privacy===<br />
There are many privacy issues with storing genetics information. Caution is advised. Some information is harmless (eg DIS information which comes from the junk part of your DNA, not used in the bleuprint) while other information can be dangerous to publish (eg hereditary diseases)..<br />
<br />
Even the genetically harmless information can be privacy infringing, as it can prove two people not to be related, which in itself can be troublesome (divorce issues, etc.).<br />
<br />
Hence some tips if you want to store this information:<br />
*set this information as private<br />
*never include private information in reports you publish<br />
*if you share information with other researchers, only share the public data<br />
<br />
For harmless genetics data, it is usefull to publish the data anonimized on a public forum. You can do that eg here on this wiki, but note that your account details will be visible in the history, so you might consider to send it to one of the administrators, or create a fake login for this reason.<br />
<br />
Eg, DYS information is usefull to relate family branches, so publishing 'last name, region of birthplace, DYS codes' gives other researchers a forum to see how related they are to you.<br />
<br />
==Y-line research==<br />
The Y chromosome plays an important role. It is only inhereted from father to son, and hence is in theory identical to the Y chromosome of the father, apart from possible variants. It is possible to commercially investigate the Y chromosome of a male, and receive marker information. A marker is a grouping on the Y chromosome, of which the structure is investigated, and cataloged. Normally markers are part of the junk DNA, so this information is in itself genetically harmless.<br />
<br />
===Y-line STR Markers===<br />
A STR marker has a specific place on the Y chromosome, indicated by a ''DYS#'' code ('''D'''NA '''Y'''-chromosome '''S'''egment), and by a specific value, called [http://en.wikipedia.org/wiki/Allele allele], which essentially is the number of repeats of a certain marker. Repeats are common in the junk part of the human DNA.<br />
<br />
There are already a 100 possible DYS markers available. Typically nowadays 12 to 37 will be tested.<br />
<br />
===How to use DYS numbers===<br />
By comparing a persons DYS profile, with that of another male, one can determine if one is direct family (identical DYS profiles), or guess based on the number of mutations how many generations ago a common ancestor lived. For this a table must be made between people with a DYS profile, with the difference in allele number<br />
<br />
{|{{prettytable}}<br />
!profile !! difference !! DYS19 !! DYS389I !! ...<br />
|-<br />
|active person || - || 14 || 12 || <br />
|-<br />
|person A || 0 || 14 || 12 || <br />
|-<br />
|person B || 1 || 15 || 12 || <br />
|-<br />
|person C || 3 || 13 || 14 || <br />
|}<br />
<br />
The less differences, the more related a person is to the person of which the profile is investigated.<br />
<br />
=== Y-DNA Haplogroups ===<br />
<br />
Less specific than STR markers, a haplogroup is defined by certain SNP mutations that occur infrequently. It is less useful for estimating degrees of relationship between individuals but useful in a broader way, since it deals with whole populations. A Y-DNA haplogroup will be the same for every male in the direct paternal line (father, father of father, father of father of father, etc), except when a "non-paternal event" occurs (i.e. there isn't a genetic contribution from the legal and recognised father).<br />
<br />
One way to use this information in a genealogy program is to allow one to stipulate the haplogroup (I2, R1b, J1a1, etc.) for an individual, and cascade that change upwards through the male line. Then allow for a way to break this chain, possibly marking the fact with a flag or visual cue.<br />
<br />
An example: a researcher tests for Y-DNA haplogroup and gets the result as R1b1. It fills the "Y-DNA Hg" attribute with "R1b1" and it is cascaded upwords (and downwards) through all the relevant lines. Donwards doesn't only apply to direct progeny: all the cousins that descend though a paternal line from a common ancestor should also be marked R1b1.<br />
<br />
Six months latter a cousin (which should be R1b1) makes the same test and gets haplogroup J2. The initial assertion is clearly wrong, and going upwards the genealogy software could pinpoint the most recent male ancestor and flag the discrepancy. This isn't limited to this kind of situations: we now have the haplogroup of several individuals deceased a long time ago, so this "most remote ancestor" could be in the 16th century.<br />
<br />
The relevance of this method is not limited to finding mismatches: the much more common situation is that different tests from different lines will yeld the same result. It even allows one to have a good idea of a certain person haplogroup without making a test.<br />
<br />
==M-line research==<br />
<br />
=== Mithocondrial DNA Haplogroups ===<br />
<br />
The same rationale and possibilities as given in Y-DNA Haplogroups apply, with the difference than Mithocondrial DNA (mtDNA) is transmitted trough the female line, and contrary to Y-DNA both males and females are able to test for it (even though it is female inherited, meaning that the mtDNA of a male is completely inherited from the mother).<br />
<br />
==Hereditary diseases/traits==<br />
In recent times, it has become possible to know the cause of death with a high degree of certainty. Also, many hereditary deviations are known, people talking about it openly. Many people will store this information in a genealogical application as eg an attribute (set private of course). <br />
<br />
This information of today, can shed light on some strange facts in your family trees history, eg many male early deaths, ...<br />
<br />
To be able to extrapolate known facts of today to the past, you need some knowledge: * is it inherited from the father or mother?<br />
* what is the possibility of inheriting the trait?<br />
* under what conditions does the trait show itself?<br />
<br />
'''Privacy''': keep this information private. Although you might not mind letting the world know men in your family are bold at 40, your cousin twice removed looking for girl might think otherwise.<br />
<br />
==Family trees for genetic research==<br />
Many research institutions have a need for extensive reliable family trees, and will employ genealogists for this purpose. <br />
<br />
It allows them to investigate traits and deviations in a broad testfield, while knowing how related the samples are.<br />
<br />
==Links==<br />
*[http://en.wikipedia.org/wiki/Genealogical_DNA_test Wikipedia: Genealogical Dna test]<br />
<br />
[[Category:Genealogy]]</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Genetics&diff=18967Genetics2009-09-16T16:18:31Z<p>Fsmunoz: /* Y-line research */</p>
<hr />
<div>{{languages}}<br />
Everybody following genealogy publications will have encountered the use of genetics in genealogy: hereditary diseases, genetic markers, ...<br />
<br />
Here we give an overview of what type of genetics data is important in genealogy.<br />
<br />
==Introduction==<br />
Humans have 23 pairs of chromosomes which form their DNA (deoxyribose nucleic acid). Each of us inherits one of each pair from one parent, and the other from the second parent. From the mother one inherits one cell of which these chromosomes form the nucleus. However, this cell also contains some genetic material which is not part of the human chromosome, called mitochondrial DNA (mtDNA), and also essential for our survival. A special role is given to the sex chromosome. For females this is a pair of X chromosomes, one from the mother, one from the father. For males however this pair consists of a X chromosome inhereted from the mother, and a Y chromosome, inhereted from the father. <br />
<br />
At each generation, 23 chromosomes are passed through to the children, constituted of material from the 23 chromosome pairs of the parents. Over time, mutations also happen, meaning that parts of the chromosome are not identical to the same parts on the DNA of the parents. Mutations that are not lethal are called variants. Some mutations happen fast, some slow, and some very slow. Should there be no mutation it would be impossible to tell how related people are one from the other. Fast mutations allow to distinguish family groups recently in time. Slow mutations allow to distinguish race groups up to ancient migration patterns, e.g. the saxon migration into Europe.<br />
<br />
===Privacy===<br />
There are many privacy issues with storing genetics information. Caution is advised. Some information is harmless (eg DIS information which comes from the junk part of your DNA, not used in the bleuprint) while other information can be dangerous to publish (eg hereditary diseases)..<br />
<br />
Even the genetically harmless information can be privacy infringing, as it can prove two people not to be related, which in itself can be troublesome (divorce issues, etc.).<br />
<br />
Hence some tips if you want to store this information:<br />
*set this information as private<br />
*never include private information in reports you publish<br />
*if you share information with other researchers, only share the public data<br />
<br />
For harmless genetics data, it is usefull to publish the data anonimized on a public forum. You can do that eg here on this wiki, but note that your account details will be visible in the history, so you might consider to send it to one of the administrators, or create a fake login for this reason.<br />
<br />
Eg, DYS information is usefull to relate family branches, so publishing 'last name, region of birthplace, DYS codes' gives other researchers a forum to see how related they are to you.<br />
<br />
==Y-line research==<br />
The Y chromosome plays an important role. It is only inhereted from father to son, and hence is in theory identical to the Y chromosome of the father, apart from possible variants. It is possible to commercially investigate the Y chromosome of a male, and receive marker information. A marker is a grouping on the Y chromosome, of which the structure is investigated, and cataloged. Normally markers are part of the junk DNA, so this information is in itself genetically harmless.<br />
<br />
===Y-line STR Markers===<br />
A STR marker has a specific place on the Y chromosome, indicated by a ''DYS#'' code ('''D'''NA '''Y'''-chromosome '''S'''egment), and by a specific value, called [http://en.wikipedia.org/wiki/Allele allele], which essentially is the number of repeats of a certain marker. Repeats are common in the junk part of the human DNA.<br />
<br />
There are already a 100 possible DYS markers available. Typically nowadays 12 to 37 will be tested.<br />
<br />
===How to use DYS numbers===<br />
By comparing a persons DYS profile, with that of another male, one can determine if one is direct family (identical DYS profiles), or guess based on the number of mutations how many generations ago a common ancestor lived. For this a table must be made between people with a DYS profile, with the difference in allele number<br />
<br />
{|{{prettytable}}<br />
!profile !! difference !! DYS19 !! DYS389I !! ...<br />
|-<br />
|active person || - || 14 || 12 || <br />
|-<br />
|person A || 0 || 14 || 12 || <br />
|-<br />
|person B || 1 || 15 || 12 || <br />
|-<br />
|person C || 3 || 13 || 14 || <br />
|}<br />
<br />
The less differences, the more related a person is to the person of which the profile is investigated.<br />
<br />
=== Y-DNA Haplogroups ===<br />
<br />
Less specific than STR markers, a haplogroup is defined by certain SNP mutations that occur infrequently. It is less useful for estimating degrees of relationship between individuals but useful in a broader way, since it deals with whole populations. A Y-DNA haplogroup will be the same for every male in the direct paternal line (father, father of father, father of father of father, etc), except when a "non-paternal event" occurs (i.e. there isn't a genetic contribution from the legal and recognised father).<br />
<br />
One way to use this information in a genealogy program is to allow one to stipulate the haplogroup (I2, R1b, J1a1, etc.) for an individual, and cascade that change upwards through the male line. Then allow for a way to break this chain, possibly marking the fact with a flag or visual cue.<br />
<br />
An example: a researcher tests for Y-DNA haplogroup and gets the result as R1b1. It fills the "Y-DNA Hg" attribute with "R1b1" and it is cascaded upwords (and downwards) through all the relevant lines. Donwards doesn't only apply to direct progeny: all the cousins that descend though a paternal line from a common ancestor should also be marked R1b1.<br />
<br />
Six months latter a cousin (which should be R1b1) makes the same test and gets haplogroup J2. The initial assertion is clearly wrong, and going upwards the genealogy software could pinpoint the most recent male ancestor and flag the discrepancy. This isn't limited to this kind of situations: we now have the haplogroup of several individuals deceased a long time ago, so this "most remote ancestor" could be in the 16th century.<br />
<br />
The relevance of this method is not limited to finding mismatches: the much more common situation is that different tests from different lines will yeld the same result. It even allows one to have a good idea of a certain person haplogroup without making a test.<br />
<br />
==M-line research==<br />
{{stub}}<br />
<br />
==Hereditary diseases/traits==<br />
In recent times, it has become possible to know the cause of death with a high degree of certainty. Also, many hereditary deviations are known, people talking about it openly. Many people will store this information in a genealogical application as eg an attribute (set private of course). <br />
<br />
This information of today, can shed light on some strange facts in your family trees history, eg many male early deaths, ...<br />
<br />
To be able to extrapolate known facts of today to the past, you need some knowledge: * is it inherited from the father or mother?<br />
* what is the possibility of inheriting the trait?<br />
* under what conditions does the trait show itself?<br />
<br />
'''Privacy''': keep this information private. Although you might not mind letting the world know men in your family are bold at 40, your cousin twice removed looking for girl might think otherwise.<br />
<br />
==Family trees for genetic research==<br />
Many research institutions have a need for extensive reliable family trees, and will employ genealogists for this purpose. <br />
<br />
It allows them to investigate traits and deviations in a broad testfield, while knowing how related the samples are.<br />
<br />
==Links==<br />
*[http://en.wikipedia.org/wiki/Genealogical_DNA_test Wikipedia: Genealogical Dna test]<br />
<br />
[[Category:Genealogy]]</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Meaningful_filenames&diff=18966Meaningful filenames2009-09-16T15:05:29Z<p>Fsmunoz: Added a possible strategy focused on Sources with multiple pages or other subunits.</p>
<hr />
<div>This article is about naming files in a meaningful way. Naturally files should have unique names so we don't end up with several files with the same or very similar names. This article takes file naming one step further by looking at how the file name itself can carry useful information about the file.<br />
<br />
This article continues on from the article about [[Portable Filenames]] where the purpose is looking at what characters (letters, numbers and symbols) we can have in our file names, and other limits on a file naming system.<br />
<br />
= Why meaningful filenames =<br />
<br />
If all names are kept unique why also try to embed meaning in the file name itself? Here are some approaches to managing information about information which which you might recognise:<br />
* File names and directory hierarchies can help describe the contents. By placing a picture called ''second birthday.jpg'' in a directory called ''My son James'' we have stored data (the picture relates to James' second birthday) about the data (the picture of the birthday party).<br />
* Data about data (called ''metadata'', ([http://en.wikipedia.org/wiki/Metadata Wikipedia's ''Metadata'' entry]) can also be stored inside the file it describes, for example:<br />
** HTML, the language of webpages, uses tags like ''<span style="normalText">Example</span>''. Here the meta data describes the style of the text, ie: ''Example'' is ''normalText''<br />
** EXIF ([http://en.wikipedia.org/wiki/Exchangeable_image_file_format Wikipedia's ''EXIF'' entry]) is a way of storing meta data in image files, like when the photo was taken and what type of camera was used. <br />
* Database systems (GRAMPS is a database system for genealogy) can store a huge amount of data about data. They're are very efficient at this job and very powerful.<br />
** Google Search uses a database to remember what web pages are about, and tells you when you ask<br />
<br />
So why not use one of those options? <br />
<br />
* EXIF is great, but only for some types of files (not supported in JPEG 2000, PNG, or GIF), there are lots of different systems for different types of files. People are working hard to improve this situation all the time. <br />
* HTML is great if you can store all your information as HTML files, but HTML files cannot contain other files, they just point to them. So we'd basically end up making a website about our files.<br />
* A database, well we already use this when we use GRAMPS. The GRAMPS database stores lots of information about the files and records it records. But GRAMPS does not store the actual file inside the database. If the connection between GRAMPS and the data it is describing is broken, then the files are just files. They contain no more information than they did when you first ''imported'' them into GRAMPS.<br />
<br />
This system of ''meaningful filenames'' has the following aims:<br />
* Preserving enough metadata to give the file's content context without GRAMPS<br />
* Creating file names normal people can understand so they can see what the file is about without GRAMPS<br />
* Creating file names which a computer can process easily so files need to be batch processed and metadata can be read directly from the file name without possible confusion<br />
* Creating a system simple enough to use all the time for every file<br />
<br />
To be understandable we need to be able to use full words where appropriate.<br />
<br />
To be computer readable we need to seperate the parts in a way which a script can easily recognise and, more importantly, in a way which would never occur in real language. So it would be no good to mark a ''name'' section with the word ''name'' if we also can use the word name somewhere in the file where it is not meant to be a marker.<br />
<br />
To be simple enough to remember the system should not be too complicated, after all GRAMPS is meant to store the real information, this is just a supplement.<br />
<br />
== What's in a name? ==<br />
It would be nice if we could have files called<br />
Marriage of Mary Angus Jones and Matthew Williams, 2nd Dec 1923 (William Angus is to Mary's right).jpg<br />
<br />
But this meets only one of the criteria above, that of ''understandable filenames''. How can a computer know who got married? what their surnames are? and so on. And anyway because of the limitations of [[Portable_Filenames]] we can't have file names like that. We have to drop the reliance on capitalisation, drop the spaces, drop the comma and drop the brackets. To be computer readable we need to separate the sections with a system of markers to indicate where the surname, event name etc are.<br />
<br />
So what sections do we want to be able to identify? Here's a basic list that should be enough for most situation, remember that GRAMPS stores the more complex information, we're just trying to give a useful structure to our files.<br />
* Surname<br />
* Firstname<br />
* Date<br />
* Event type<br />
* Place<br />
* Source<br />
* Note<br />
<br />
Some more important criteria. All file names:<br />
* Must be unique<br />
* Must have all necessary information<br />
* Must have no more information than necessary<br />
<br />
So if I find a file somewhere strange in my system, or if someone I sent a file to seven years ago says "that file you sent me - that's not Jean it's her daughter" I know where my archive copy of that file will be.<br />
<br />
= GEDCOM based =<br />
This is a system contributed by [[User:Duncan|Duncan Lithgow]].<br />
<br />
== Tags ==<br />
If we base a naming system on the 3 and 4 letter [http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcappa.htm Lineage-Linked GEDCOM Tag Definition] used in the GEDCOM 5.5 standard we have a good long list of tags to chose from. By limiting the GEDCOM tags list we can make the following shortlist (which does not include events):<br />
<br />
'''AUTH--''' Author "The name of the individual who created or compiled information."<br />
'''DATE--''' Date<br />
'''EVEN--''' Event "A noteworthy happening related to an individual, a group, or an organization."<br />
'''GIVN--''' Given name "A given or earned name used for official identification of a person."<br />
'''NAME--''' Name, use only if GIVN and SURN are not known "A word or combination of words used to help identify an individual, title, or other item. More than one NAME line should be used for people who were known by multiple names."<br />
'''NOTE--''' Note "Additional information provided by the submitter for understanding the enclosing data."<br />
'''PLAC--''' Place "A jurisdictional name to identify the place or location of an event."<br />
'''REFN--''' Reference "A description or number used to identify an item for filing, storage, or other reference purposes."<br />
'''SOUR--''' Source "The initial or original material from which information was obtained."<br />
'''SURN--''' Surname "A family name passed on or used by members of a family."<br />
'''TITL--''' Title "A description of a specific writing or other work, such as the title of a book when used in a source context, or a formal designation used by an individual in connection with positions of royalty or other social status, such as Grand Duke."<br />
<br />
Each marker ends with two hyphens (--). Two because we can't rely on the marker being recognised as capitalised, so a surname like ''Besour-Jean'' could be mistaken for ''beSOUR-Jean'' and the system thinks that ''SOUR-'' marks a ''source'' section.<br />
<br />
== Punctuation ==<br />
In order for the file name to be parsed as meaningful text I think some we also would need<br />
<br />
'''_''' Underscore to represent a space<br />
'''__''' Double underscore to represent a comma followed by a space<br />
<br />
== Source events ==<br />
The GEDCOM 5.5 standard defines so few events as to be useless. The GRAMPS XML schema defines no events as these can be made by the user. This all seems fair enough since events are highly culture based. The situations where I think a set of events should be defined are those which will be connected with source records. GEDCOM has a reasonable group of those but they are heavily based in western christian culture. The solution must be language and culture dependent. Here's my list:<br />
<br />
'''marriage''' is for an actual marriage event and all the associated documentation, including possible divorce and separation documentation.<br />
'''birth''' is for the actual birth records, also christening record<br />
'''death''' is for death records<br />
'''census''' is for census records<br />
'''civic''' is for military service records, and government records of any type<br />
'''health''' is for health records<br />
<br />
== An event image file ==<br />
<br />
File name:<br />
EVEN--marriage_SURN--jones_GIVN--mary-jean_SURN--williams_GIVN--matthew_DATE--1923-12-02_NOTE--william_angus_to_right_of_mary.jpg<br />
<br />
This could be parsed (by GRAMPS?) as the description:<br />
<br />
'''Event:''' Marriage<br />
'''Surname:''' Jones<br />
'''Given name:''' Mary-jean<br />
'''Surname:''' Williams<br />
'''Given name:''' Matthew<br />
'''Date:''' 2nd Jan, 1923<br />
'''Note:''' William angus to the right of mary<br />
<br />
or it could make the text:<br />
<br />
Mary-jean Jones and Matthew Williams, marriage 2nd Jan 1923. (William angus to the right of mary)<br />
<br />
== A source image file ==<br />
<br />
File name:<br />
SOUR--census_PLAC--uk__england__london_DATE--1840-03-21_SURN--jones_GIVN--mary-jean.pdf<br />
<br />
This could be parsed (by GRAMPS?) as the description:<br />
<br />
'''Source:''' Census<br />
'''Place:''' Uk, england, london<br />
'''Date:''' 21st March, 1840<br />
'''Surname:''' Jones<br />
'''Given name:''' Mary-jean<br />
<br />
or it could make the text:<br />
<br />
Census, Place: Uk, england, london, on 21st March 1840. This is a source connected to Mary-jean Jones<br />
<br />
== A source text ==<br />
<br />
File name:<br />
SOUR--publication_TITL--the_jones_family_from_1735_AUTH--mary_jean_jones_DATE--1872.pdf<br />
<br />
This could be read as the description:<br />
<br />
'''Source:''' Publication<br />
'''Title:''' The Jones Family from 1735<br />
'''Author:''' Mary Jean Jones<br />
'''Date:''' 1872<br />
<br />
Or it could make the text:<br />
<br />
"The Jones Family from 1735" by Mary Jean Jones, 1872<br />
<br />
== SWOT analysis ==<br />
Over at Wikipedia there is a good explanation of a [http://en.wikipedia.org/wiki/SWOT_analysis SWOT analysis].<br />
<br />
{| {{prettytable}}<br />
|-<br />
! Aspect<br />
! Strengths<br />
! Weaknesses<br />
! Opportunities<br />
! Threats<br />
|-<br />
| File length<br />
| Holds a lot of information<br />
| All the information is already in the genealogy software<br />
| Easily recognised. Easy to search for files with a certain [[Tag]]<br />
| ?<br />
|-<br />
|}<br />
<br />
= GRAMPS ID based =<br />
<br />
This is another attempt by [[User:Duncan|Duncan Lithgow]] to find a good system. It is not finshed so feel free to add comments and correct any obvious mistakes.<br />
<br />
Here's the records we'll use as examples. They involve Mary Agnes Williams (daughter of John Williams and Anna Matthews). She married Anders Sørensen (son of Anders Sørensen and Anna ?) and they had a daughter Anna Sorensen, note the spelling change.<br />
<br />
* Census record: mentioning her and her siblings and parents. It is from the 1810 census in the London parish of Dangerfield on Saint John Road.<br />
* Portrait: a hand drawn portrait of Mary, undated, assumed to be from before her marriage.<br />
* House picture: her parent's Saint John's Road row house in London, from some time around 1810's<br />
* Court record: Anders Sørensen was before the district court for drunk and unbecoming behaviour on January 3rd, 1820. Engelfield, London.<br />
* Marriage certificate: She married Anders Sørensen, 2nd December 1823, in London.<br />
* Wedding portrait: in the picture is Anders Sørensen's father, also called Anders Sørensen (on the back it says that Anders Sørensen's (the son) mother is called Anna).<br />
* Birth certificate: of Anna Sorensen (daughter of Mary and Anders) dated January 18th, 1824<br />
* Family tree: a hand written family tree called "The Dean family from 1735" by an Angus Dean written in 1972 which connects the families Dean and Williams.<br />
<br />
== Justification ==<br />
<br />
{{stub}}<br />
<br />
== Aims ==<br />
<br />
This system tries to meet the following aims:<br />
* simple enough to remember<br />
* just enough information, and no more<br />
* all media for one family name is under one directory (portability for travel)<br />
* all media for generating reports is under one directory (for portability)<br />
<br />
== Record types ==<br />
<br />
The record types tell us what the record is about. GRAMPS ID's use the first character to denote the type of item the ID refers to. Sticking to something already thought and taking the most relevant ones to stored records these can be used as the following tags for record types:<br />
<br />
* I-- Individual<br />
* P-- Place<br />
* E-- Event<br />
* S-- Source <br />
<br />
(see also source types)<br />
<br />
'''Question'''<br />
* Records about repositories?<br />
* Correspondence with family?<br />
* What about records covering more than one type?<br />
* What will happen on old 8+3 file systems?<br />
<br />
== Record properties ==<br />
<br />
Properties tell us just enough information to make the file name meaningful and recognisable, and split this information up so we can search for parts of it with our file manager. It's the what, where, when, why and how of what's in the record.<br />
<br />
By making all properties of each record compulsory we avoid extra tags like GN for given name and so on. We can see what a property is by where it is in the file name.<br />
<br />
* family name is their surname before marriage, but including deed pool changes, MacArthur for example<br />
* given name is their official first name<br />
* uid is a unique identity, in this example the (original) GRAMPS ID of the media file<br />
* source date is the date in ISO 8601 format when the information left the people or organisation responsible for it<br />
* event date is the date in ISO 8601 format when the event occured or started. YYYY-MM-DD, ie. 2008-12-28<br />
* event type is a noun describing the event, chosen from a list of event types, ie: marriage<br />
* title is the name of a document (book, letter, census) or object (gravestone, heirloom), ie. williams__arthur_headstone<br />
* source author name is the name of the person or organisation most responsible for the information. For people always use family name first followed by two underscores (__), ie: church_of_lds<br />
* note is for notes. Names should always be family name first followed by a double underscore<br />
<br />
== Naming structure ==<br />
<br />
Now we can outline a single schema for all record types in which the following rules apply.<br />
<br />
* File names are written directly to the file name, not copied from another program.<br />
* File names start with a single capital letter representing their record type.<br />
* Record properties are separated by two dashes (--). This can not be used for anything else.<br />
* Missing information is replaced by a single underscore (_).<br />
* Names in notes should always be family name first and separated by two underscores, ie: ''doe__john'' which can be represented as ''John Doe'' or ''Doe, John''.<br />
* Place names should start with the largest geographical region followed by a double underscore before the next geographical region, ie: ''oz__far_far_away__yellow_brick_road'' which can be represented as ''Oz, Far far away, Yellow brick road''.<br />
* If the family name is unknown it must be replaced by an underscore. This will give three consecutive underscores (___), ie: ''___john''' should always be interpreted as meaning ''[no record], John''.<br />
* event types should always be drawn from a list to avoid separate words being used for the same event type. (Maybe use the event list gramps uses?)<br />
<br />
# <record type>-- (I, P, E or S)<br />
# <source type/event type>-- (needs expansion.)<br />
# <1st persons family name[__2nd persons family name]>-- (two names for couples or families, alphabetical)<br />
# <1st persons given name(s)[__2nd persons given name(s)]>-- (two names for couples, same order as for family names)<br />
# <country code__region__city>-- (use as many divisions as needed)<br />
# <date>-- (ISO date, YYYY-MM-DD)<br />
# <note>-- (usually not needed)<br />
# <uid> (a Unique ID, possible derived from the gramps ID)<br />
<br />
Here's a version of the naming structure for quick reference.<br />
<br />
Record_type--source_or_event_type--family_name__s--given_name__s--cc__city__place--YYYYMMDD--note--uid<br />
<br />
== Examples ==<br />
<br />
Using the records outlined in the beginning we would get the following file names. (Please help complete this list of examples)<br />
<br />
* Census record: ''S--census--matthews__williams--anna__john--uk__london__dangerfield__st_johns_rd--1810-_-_--_-00874.pdf''<br />
* Court record: ''S--court_record--soerensen--anders--uk__london__engelfield--1820-01-03--before_district_court--00826.pdf''<br />
* Marriage certificate: ''S--marriage_certificate--jensen__williams--anders__mary_agnes--uk__london--1823-12-02--_--00864.pdf''<br />
* Portrait: ''I--portrait--williams--mary_agnes--uk__london--1823-12-03--wedding_portrait--000967.jpg''<br />
<br />
= Source based =<br />
<br />
One possible shortcoming of using an event and/or individual based naming strategy is that it could "clash" with the relation between a filename and the source. This only applies to filenames that are a representation of a specific part of a source.<br />
<br />
An example: having found the baptism record of Anna in page 51v of the 1843-1850 Baptism book of a certain Church we save the image (which displays pages 50v and 51f, i.e. it is an image of the "open book") and name it something like BAP--Anna--1850.png (just an example, any individual and role based mechanism will yeld similar results). This works fine and allows one to easily extrapolate information from the file name.<br />
<br />
However, we latter find that in the exact same page, but a few paragraphs below, we have the baptism record of another individual, from another part of the family tree. While we can simply use the original file it wouldn't convey the right information. We can duplicate the file, but that doesn't make much sense, especially since when adding the file to the Source gallery we would end up with a duplicate, which makes little sense.<br />
<br />
One way to deal with this is to use a purely source-based approach in naming the files. The downside is that event and individual information can't be gleaned by looking at the file name - one would have to use GRAMPS itself to maintain the appropriate relations, which is after all something that is part of the source referencing work that should be done. On the other hand, and when talking about Sources that are books, it allows for easy grouping of content related to the same source, e.g. all the relevante pages on a certain book. An example filename would be "PBL--BAP3--F51-52.png", where PBL is the short name of the source author and BAP3 the short name of the specific source. Longer, more descriptive filenames could be used by using full names instead of codes.<br />
<br />
Obvisously this method is limited in scope to some kinds of sources, and doesn't make sense for naming photos or documents that aren't part of a larger source (e.g. an ID card).<br />
<br />
= See also =<br />
* [[Organise your records]]<br />
* [[Portable Filenames]]<br />
<br />
= External links =<br />
* [http://www.northernjourney.com/photo/articles/filenaming.html File Naming Conventions for Digitally-stored Images]<br />
* [http://en.wikipedia.org/wiki/Metadata Metadata] at Wikipedia - data about data<br />
* [http://en.wikipedia.org/wiki/Meta_tags Meta tags] at Wikipedia<br />
* [http://en.wikipedia.org/wiki/Ontology_(computer_science) Ontology in computer science] from Wikipedia<br />
* [http://en.wikipedia.org/wiki/Library_science Library science] from Wikipedia<br />
* [http://www.43folders.com/2006/10/23/file-naming?page=2 File naming] at 43folder.com<br />
* [http://whatdoiknow.org/archives/000442.shtml File Naming / Organization Methods?] from [http://whatdoiknow.org What do I know?]<br />
<br />
[[Category:Documentation]]<br />
[[Category:Developers/General]]</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Talk:Portal:Genealogy&diff=18965Talk:Portal:Genealogy2009-09-16T14:26:56Z<p>Fsmunoz: /* Portal Genealogy - moving */</p>
<hr />
<div>= Proposal to move genealogy advice outside this wiki =<br />
I think we should do this, but I don't think we have found the right solution yet. Damn, I thought I had... --[[User:Duncan|DuncanNZ]] 09:33, 16 October 2008 (EDT)<br />
<br />
== Reasons for the move ==<br />
* Credibility is improved by keeping advice separate from a specific software solution<br />
* The GRAMPS wiki is relatively small and presumably gets few non-GRAMPS users visiting<br />
* Supporting the best existing sites about genealogy reduces duplication of effort<br />
* Involvement in more active (and diverse) websites increases the potential for collaboration and original solutions and thoughts<br />
<br />
== Current problems with moving ==<br />
* There are no good multilingual sites<br />
* Internal inks in this site need to be preserved (so don't actually delete a page, leave a link to the new location)<br />
<br />
== Wishlist for genealogy advice website ==<br />
(Please sign your wishes so we can discuss them on the email lists)<br />
* Fully multi-lingual (Jerome), --[[User:Duncan|DuncanNZ]] 09:33, 16 October 2008 (EDT)<br />
* The site must use a free license (free to use, modify and distribute) --[[User:Duncan|DuncanNZ]] 09:33, 16 October 2008 (EDT) ([http://help.ubuntu.com/community help.ubuntu.com/community] uses [http://creativecommons.org/licenses/by-sa/3.0/ BY-SA] )<br />
* Consensus among wiki editors on which site to use, so we can endorse it for readers as our preferred choice. --[[User:Duncan|DuncanNZ]] 09:33, 16 October 2008 (EDT)<br />
* Site should aggregate from other sites' content, to avoid duplication (what's this called?) --[[User:Duncan|DuncanNZ]] 09:33, 16 October 2008 (EDT)<br />
<br />
=== Suitable licenses ===<br />
* [http://www.gnu.org/copyleft/gpl.html GPL] is OK for [http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html Debian]<br />
* [http://creativecommons.org/licenses/by-sa/3.0/ BY-SA v3.0] is OK for [http://help.ubuntu.com/community help.ubuntu.com/community Ubuntu], but is it OK for Debian?<br />
* [http://www.gnu.org/copyleft/fdl.html GFDL] is OK for Debian (but they don't like it) only if there is no [http://en.wikipedia.org/wiki/GNU_Free_Documentation_License#Criticism_of_the_GFDL 'invariant text']. They say that in August 2008, but which version are they talking about? See if you can work it out: [http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html Debian Documentation Policy (DRAFT)]<br />
<br />
=== Unsuitable licenses ===<br />
* Creative Commons Licenses, version 2.0 or 2.5 ([http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html Debian, August 2008])<br />
* Creative Commons BY-NC-SA, preventing commercial use is not 'free' by the Debian definition<br />
<br />
== Comparison of potential websites ==<br />
The column 'Redistributable with Debian?' is there because Debian has the most restrictive policy on including documentation.<br />
<br />
{| border="1" class="wikitable sortable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;"<br />
|-<br />
! Website<br />
! License<br />
! Positive points<br />
! Negative points<br />
! Redistributable with Debian?<br />
|-<br />
| [http://genealogy.wikia.com/wiki/Main_Page Familypedia]<br />
| [http://www.gnu.org/copyleft/fdl.html GFDL]<br />
| Has over 24,400 articles (and [http://wikistats.wikia.com/wikistats/EN/TablesWikiaGENEALOGY.htm about 60,000 other pages]) with advanced use of categories and templates; [http://genealogy.wikia.com/wiki/Category:Multilingualism accepts any language]<br />
| Genealogy advice and records share the same wiki<br />
| {{yes}} without 'invariant text'<br />
|-<br />
| [http://www.werelate.org/wiki/WeRelate:About WeRelate.org]<br />
| [http://www.gnu.org/copyleft/fdl.html GFDL] (text) <br />
| Claim 2,000,000 entries. By the registered charity [http://www.folg.org/ Foundation for On-Line Genealogy]<br />
| Genealogy advice and records share the same wiki<br />
| {{yes}} without 'invariant text'<br />
|-<br />
| [https://wiki.familysearch.org/en/Main_Page FamilySearch]<br />
| [http://creativecommons.org/licenses/by-nc-sa/3.0/ BY-NC-SA]<br />
| FamilySearch Wiki is [only] about genealogical research advice.[https://wiki.familysearch.org/en/The_Vision:_Why_We_Built_FamilySearch_Wiki#Subjects_outside_the_wiki.E2.80.99s_scope (ref)]<br />
| [http://creativecommons.org/licenses/by-nc-sa/3.0/us/ BY-NC-SA] means no commercial use.<br />
| {{no}}<br />
|-<br />
| [http://www.genealogywiki.org/ GenealogyWiki.org]<br />
| A Creative Commons license, but the license link is dead. I've written to them but had no response.<br />
| Is only for genealogy information, not articles and thoughts.<br />
| Is only for genealogy information, not articles and thoughts.<br />
| {{?}}<br />
|-<br />
-<br />
| [http://www.geneawiki.com GeneaWiki]<br />
| [http://www.geneawiki.com/index.php/GeneaWiki:Copyright BY-NC-SA]<br />
| + in french, very active<br />
| - most part in french, [http://en.geneawiki.com/index.php/Main_Page english] available<br />
| {{no}}<br />
|-<br />
<!-- ### Genealogy Wikibook ### --><br />
| <!-- Website -->[http://en.wikibooks.org/wiki/Genealogy Genealogy Wikibook]<br />
| <!-- License -->[http://www.gnu.org/copyleft/fdl.html GFDL]<br />
| <!-- Positive points -->Hierarchic book structure improves navigation<!--"improves" over what? Any MediaWiki site can have book-like structures and other navigation shortcuts--><br />
| <!-- Negative points -->Not very active<br />
| <!-- Redistributable with Debian? -->{{yes}} without 'invariant text'<br />
|-<br />
<!-- ### TEMPLATE, make a copy before you start ### --><br />
| <!-- Website -->TEMPLATE[url name]<br />
| <!-- License -->[url license]<br />
| <!-- Positive points -->{{?}}<br />
| <!-- Negative points -->{{?}}<br />
| <!-- Redistributable with Debian? -->{{?}}<br />
|-<br />
|}<br />
<br />
= Archive =<br />
(Move old content down here if it should be kept for reference)<br />
<br />
(Bob's question was answered three months ago. Text deleted. --[[User:Duncan|DuncanNZ]] 09:14, 16 October 2008 (EDT))<br />
<br />
I've just spotted the + indicating access to this discussion - should be more obvious! <br />
<br />
It seems to me that the Genealogy Wikibook (last in the tabulated list) is the most appropriate place for this portal - perhaps even combined? The purposes appear to be similar. <br />
<br />
The comment "little used" suggests that a few more links would be useful. <br />
Yours sincerely,<br />
<br />
Theo Tulley.<br />
<br />
tj.tulley@physics.org<br />
SFHG Member No: 11619<br />
<br />
== Portal Genealogy - moving ==<br />
<br />
Returning to this - FamilySearch appears to be removed from consideration because it is shown as not redistributable with Debian. <br />
<br />
It is however an excellent facility, and I can access it using Firefox in a LinuxMint-6 system. <br />
<br />
I'm a Newbie in these matters, but I understand that LinuxMint is a derivative of Ubuntu, itself a derivative of Debian. What is required beyond the ability to access it? <br />
<br />
The title FamilySearch however invites confusion with the (free) Ancestry.com site. <br />
<br />
Theo Tulley.<br />
<br />
:: The problem is not the accessing (i.e. reading) of the information, but if you can, for example, make a dump of the wiki and distribute it on a CD or as a package, and modify the contents, etc. So it's a matter of licencing, hence the reference to Debian since they have clearly defined lines about what constitutes free documentation and what doesn't. As such being able to be "distributed in Debian" is a way to express that the resource should pass the Debian criteria for free documentation. The FamilySearch site, for example, which is one of the best in terms of practical advices and practices, uses a licence that prohibits commercial pro-profit distribuition, and as such falls short o being considered free documentation, and GRAMPS will not advice the use of a wiki whose content isn't free to use, modify and redistribute. --[[User:Fsmunoz|Fsmunoz]] 14:26, 16 September 2009 (UTC)</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Names_Discussion&diff=18898Names Discussion2009-09-10T21:21:13Z<p>Fsmunoz: Some initial comments to give the background</p>
<hr />
<div>There is some complex discussion about how the names system in GRAMPS can be improved in future versions. There is a bug: http://www.gramps-project.org/bugs/view.php?id=3161 and an email thread: http://www.nabble.com/Proposals-for-additional-name-fields-tt25356341.html<br />
<br />
This page tries to collect and organise the discussion.<br />
<br />
= Definitions =<br />
<br />
Patronymic: http://en.wikipedia.org/wiki/Patronymic<br />
<br />
Middle name: http://en.wikipedia.org/wiki/Middle_name<br />
<br />
Plural last names: http://en.wikipedia.org/wiki/Middle_name#Spain_and_Latin_America<br />
<br />
Family name: http://en.wikipedia.org/wiki/Family_name<br />
<br />
Portuguese names: http://en.wikipedia.org/wiki/Portuguese_name<br />
<br />
Spanish names: http://en.wikipedia.org/wiki/Spanish_naming_customs<br />
<br />
= Explanation =<br />
<br />
Some relevante quotes from the links above<br />
<br />
''...In the case of Portuguese naming customs, the main surname (the one used in alphasorting, indexing, abbreviations, and greetings), appears last (reverse the order of Spanish surnames)...''<br />
<br />
''...However, nowadays in Spain and in many Spanish-speaking countries (...) most people have two family names, although in some situations only the first is used. The first family name is the paternal one, inherited from the father's paternal family name. The second family name is the maternal one, inherited from the mother's paternal family name...''<br />
<br />
''...The son of Juan Carlos Pérez Larios and Susana Estela Ríos Domínguez, if given the same first name of his father, would be Juan Carlos Pérez Ríos. Pérez is the "important" last name and the one used if only one is needed...''<br />
<br />
The reference to a "main surname" and "important last name" is one of the points to have in mind. There are differences between the Spanish and Portuguese naming customs, but this much can be generalised I think:<br />
<br />
* The presence of more than one surname, typically taken from both the father and the mother<br />
* The possibility of having more than two surnames, taken from both parents and in some cases from grandparents<br />
* The "main" surname (i.e. the one used in indexing, for example, or the one generally used to denote family affiliation) is not always in a fixed position<br />
<br />
The patronymic can be "hard" or "soft", for lack of a better terms, and by this I mean that in medieval times the "surname" was actually a patronymic (Henrique -> Afonso Henriques, etc.), while other times the patronymic is added along with surnames (Rodrigo Garcia -> Gonçalo Rodrigues Garcia). The patronymic is a somewhat different discussion, not directly related to the "multiple surnames" one.<br />
<br />
Since existing fields are Given Name and Family Name one would end up, if following the meaning of those words to the letter, to do something like this:<br />
<br />
Complete Name: José de Mascarenhas da Silva e Lencastre<br />
Given Name: José<br />
Family Name: de Mascarenhas da Silva e Lencastre<br />
<br />
This is semantically correct, but obscure the real meaning of the name: D. José de Mascarenhas can be said to belong to the Mascarenhas family, and not to the "Mascarenhas da Silva e Lencastre" one.<br />
<br />
The general usage I've seen falls within these options:<br />
<br />
* Use Given Name for all surnames except the last: this is common in Portugal (and related countries in terms of naming customs) since the last name is nowadays almost always the "main" family name.<br />
* Use Family Name to contain all the surnames: these needs some "group as..." tweaks to work.<br />
* Use some other field in a custom way: generally a bad idea, since consistency is not guaranteed or even expected when using the data for other purposes (reports, etc.)<br />
<br />
The discussion is about adding some field (or some other solution) to make the data entry more logical and less likely to need "kludges" in order to appear as expected, both in reports, in the daily use of the program and in terms of expected behaviour (grouping, pre-filling of surnames when adding, etc).<br />
<br />
<br />
= Example names and explanations =<br />
* Henri de Blier, son of Collard, sometimes referred to as Henri Collard de Blier<br />
* João Soares de Sousa<br />
** given name(s): João, middle name: Soares (first surname), surname: de Sousa (second surname)<br />
* Joe (the hitter) Silva de Souares<br />
** Given name: Joe, Nickname: The Hitter, Secondary surname: Silva, First surname: Souares, prefix to first surname: de<br />
* Santiago Ramón y Cajal<br />
* García Álvarez de Toledo y Carrillo de Toledo<br />
* José de Mascarenhas da Silva e Lencastre<br />
** given name: José, Family surname: Mascarenhas, prefix to Family surname: de, additional surnames: [da] Silva [e] Lencastre<br />
<br />
= Options =<br />
(every idea we have for now)<br />
<br />
== Option 1 ==<br />
[Given Names] [Middle Name(s)] [Family Name]<br />
Comments: (signed)<br />
<br />
== Option 2 ==<br />
[Given name] [Secondary Surnames] [Family Name]<br />
Comments: (signed)<br />
<br />
== Option 3 ==<br />
[Given Names][Family Name][Secondary Surnames]<br />
Comments: (signed)<br />
<br />
= Table of names =<br />
(to be populated once we have a proposed set of headings)</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=User:Fsmunoz&diff=8260User:Fsmunoz2008-09-18T23:11:38Z<p>Fsmunoz: New page: Trying to learn, and writing about it in the process.</p>
<hr />
<div>Trying to learn, and writing about it in the process.</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Talk:Repositories_in_Gramps&diff=8238Talk:Repositories in Gramps2008-09-18T10:59:16Z<p>Fsmunoz: </p>
<hr />
<div>Are ...<br />
What should be done ? [[User:Romjerome|romjerome]]<br />
== Initial Version ==<br />
Following a thread in the list I've made this initial version, focused on the Sources->Repository relation.--[[User:Fsmunoz|Fsmunoz]] 06:59, 18 September 2008 (EDT)</div>Fsmunozhttps://gramps-project.org/wiki/index.php?title=Repositories_in_Gramps&diff=8237Repositories in Gramps2008-09-18T10:50:54Z<p>Fsmunoz: Initial version</p>
<hr />
<div>Repositories can be thought of as a collection of sources and can be seen as representing the origin and location of a specific version of a source. Each source can reference one or more Repositories: this association is made in the Repositories tab in the Source editor.<br />
== Repositories example ==<br />
To better illustrate some of the possible use scenarios consider the following data that we want to record in GRAMPS:<br />
<br />
Name: Raphael Hythloday<br />
Birth date: 20 February 1480<br />
Place of Birth: Santa Maria de Belém, Lisbon, Portugal<br />
Source: Baptism record present in page 66 of the year 1480 book of the Baptism Records of the Parish of Belém in Lisbon, Portugal<br />
<br />
=== Single Repository ===<br />
With the above information the following structure can be deduced, from the higher level Repository information to the actual Source reference in the birth event:<br />
<br />
Repository: Parish of Belém Archives<br />
Source: Parish of Belém Baptism Records<br />
Event source reference: In the "Vol/Page" field input "Year 1480, page 66"<br />
<br />
It becomes apparent that the Repository is ultimately the "physical" location of the sources - truly physical in this example since it represents a specific building of a specific institution, but could also be a Web repository. <br />
<br />
=== Multiple Repositories for the same Source ===<br />
<br />
The example above has as source a Baptism Record book of a Parish. While this is the source of the birth event - and possibly others - it is possible that multiple representations of this single source exist. Let's consider a not unusual scenario:<br />
<br />
* The book itself in the Parish Archives, as already mentioned.<br />
* A microfilm of Baptism Records of the same Parish covering 1480-1500 is present in the Lisbon District Archive, with the number MF-123456<br />
* A scanned image and transcription of the same baptism record is available online in the National Archive webpage.<br />
<br />
The source itself remains the same: the Baptism Books of the Belém Parish, so it is hardly practical or necessary to add different Sources to represent the different mediums in which the information lies. It is however useful to record that the information is available in different ways and forms - it might, for example, be necessary to get a copy of the Baptism record at a latter time.<br />
<br />
Repositories - and the associated reference in the Sources - fulfil this task: they represent different origins and representations of the same source. Using the above information 3 different Repositories exist:<br />
<br />
# The already added Parish of Belém Archives<br />
# The Lisbon District Archive<br />
# The National Archive Digital Repository<br />
<br />
The same source - the already referenced "Parish of Belém Baptism Records" - should be added to all three. When a source is added to a Repository a Repository Reference is created. This reference shows the shared Repository information - that is the same for all the Sources in the same Repository - and also a Reference Information section that is specific to the Source and that includes "Media Type" and "Call Number". This is where the information that is required to locate the source in the repository should be entered. Following our example:<br />
<br />
# The Baptism books "proper" would have as Repository the Parish of Belém Archives. The "Media Type" in the Repository information would be set to "Book" and the call number empty.<br />
# The microfilm would have as Repository the Lisbon District Archive. The "Media Type" would be "Microfilm" and the call number "MF-123456".<br />
# The scanned image available online would have as Repository the national Archive. The "Media Type" would be "Web page" (or perhaps "Digital image") and the call number the URL where the image is available.</div>Fsmunoz