From: John R. <jr...@ce...> - 2013-07-21 21:44:40
|
On Jul 21, 2013, at 11:28 AM, jerome <rom...@ya...> wrote: > >> I don't understand what the European Regional Policy has to do with > anything, nor what interaction with locale you're asking about. > > It was an illustration, Germany/Czech Republic, France/Germany, Spain/Portugal, etc ... have common history close to borders. FamilySearch is indexing archives based on country level. Sometimes for effectiveness, we should rather use "level +1" (multiple countries), sometimes "level -1" (regions/provinces/US states), into place hierarchy. > > > It should point out the limit of current lang handling into Gedcom X around the sources collection logic. > Neither conclusions or locations can have only one simple unique lang attribute, even optional. > US borders like Mexico/USA, Canada/USA, Caribbean/USA, Central America/USA are also recent borders, but you cannot say that old sources in Los Angeles are the same as in Chicago or Miami. Currently, in France, you can easily find a census source in French and related birth transcription into dialect/patois/latin/german/(hebrew,yiddish?)/creole/vernacular, etc ... or the most common French! https://en.wikipedia.org/wiki/Vernacular > > That's why I looked at a solid lang handling and also flexible for be able to work outside a border without having to move into a new sources collection/group/department, which seems still into FS plans? > > eg, I cannot imagine that people looking at sources written into West 'German' Yiddish, Breton, Occitan, Athabaskan, etc ... will set a country. In this case, I suppose the names, note, source, place etc ... translations will fail into Gedcom X? > Jérôme, GedcomX has nothing at all to do with FamilySearch's indexing or cataloguing practices. It's a protocol for exchanging genealogical data, run by a separate team. Yes, it's true that one may find documents in different languages than might be assumed from their location's locale. A thorough researcher will find the *original* document and, if it's in a language which she can't read, will get the assistance of a qualified translator to render it into her own language. She'll keep detailed notes of what the original document is and where it came from and how she decided that the translator was qualified and competent. GedcomX has Notes that can be attached to just about anything, just like Gramps. When we get around to writing a GedcomX exporter, we need to make sure that all of the Note objects in a database get turned into GedcomX Notes and that they're attached to the right objects in GedcomX, and vice-versa on import. Everything you write will be in some language. In my case, it's going to be English, because I'm not good enough in any other language. In your case, French, English, and maybe others, but usually one at a time. GedcomX provides a 'lang' tag on just about everything, so it's possible to tag each Note, TextValue, Citation Value, Conclusion (remmeber that's a superclass), and Name Form separately. Gramps AFAIK doesn't support any of that: We only know about the language that the user wants us to use to display the GUI or to write the translatable strings in a report -- nothing about what language the user is actually writing in. Maybe capturing that would make a good GEP. Is that what you're after, or am I still misunderstanding you? Regards John Ralls |