Utskriftsvy
När jag får mina svarsfiler så är de encodade i oldfashined 8 bits. Varför ?. Det är tyvärr inte övergivet ännu. En mera modern encoding är utf8 som också klarar av en massa utländska tecken förutom åäö. För att tillgodose alla önskemal kan man använda
taggen HEAD.CHAR och generera svarsfiler enligt den taggen.
Regards.
PS. Hur är progressen med modernisering utav dispyt DS.
Jag ska lyssna vad som är möjligt att enkelt genomföra när det teckenkodning. När det gäller nya söksidan så står vi i begrepp att gå ut med, som vi hoppas, den sista betan innan vi släpper en publik beta parallellt med nuvarande Disbyt.
Jag har skrivet ett ärende #4329 men utvecklaren är utomlands ett par veckor till så jag tror att svaret dröjer.
Disbyt-basen har varit med så länge, så den första teckenuppsättningen i basen var ASCII-7. I dagsläget är teckenuppsättningen ANSI-8.Citat:
Ursprungligen postat av penguinfriend
Filer som tas emot checkas för olika teckenformat: ASCII, ANSI, MAC, UTF8 mm men konverteras till ANSI. Det innebär att vi inte tar höjd för alla teckenvarianter som finns i UTF8. Å andra sidan har fokus på Disbyt alltid varit svenskt material, så en total internationalisering har inte varit aktuellt.
Att konvertera teckenformat i själva Disbyt-basen till UTF8 kräver mycket arbete med att kolla koden. Delar av koden har mer 25 år på nacken. Det är ingen högprioriterad fråga i dagsläget.
När det gäller teckenformat på resultatfilerna i Disbyt, så är jag ganska säker på att de som skickar in material med MAC-teckenkodning får tillbaka resultatet i samma format. Jag trodde nog att det också gällde de som använder olika PC-teckenkodningar, men jag får kolla det framöver när jag är tillbaka i Sverige.
Med hälsning från Stillwater, Minnesota
/Olof C
Min Gedcomfil har följande infi i headernCitat:
Ursprungligen postat av m00082
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 LANG Swedish
men när jag får mina svarsfiler ser det ut som följer: (utdrag från A****.TXT)
Först så varnar den att det är en binär fil och sedan ser det ut:
Resultat av DISBYT-s<F6>kning med s<F6>kfil f<F6>r medlem 49812 utf<F6>rd 2017-09-24
Niv<E5> 3 - Efternamn och ort <E4>r identiska. <C5>rtalen <F6>verlappande.
Niv<E5> 4 - Hela namnet och orten <E4>r identiska. <C5>rtalen <F6>verlappande.
Niv<E5> 5 - Hela namnet, orten och ett <E5>rtal <E4>r identiska.
Niv<E5> 6 - Hela namnet, orten och b<E5>da <E5>rtalen <E4>r identiska.
Niv<E5> 7 - Hela namnet, orten och ett <E5>rtal <E4>r identiska. Sl<E4>ktingar finns med tr<E4>ffar.
Niv<E5> 8 - Hela namnet, orten och b<E5>da <E5>rtalen <E4>r identiska. Sl<E4>ktingar finns med tr<E4>ffar.
F<F6>r- och efternamn kan vara normerade j<E4>mf<F6>rt med medlemmens egna uppgifter.
dvs den ger ISO/IEC 8859-1 fastän infilen var skriven i UTF-8.
Du skrev också att databasen är skriven i 8 bits men jag bryr mig inte om vad den har för internformat utan vad den ger som utfil. Eftersom teckenuppsättning är jobbigt så
vill jag bara ha utf8 i mina datorer.
Låt detta vara sista ordet i denna tråd.
Vem är "den" som varnar för att det inte är en textfil? Vilket program använder du för att öppna textfiler?Citat:
Ursprungligen postat av penguinfriend
Det är inget progran utan OS (Linux):ohmy:
Använder 'less' som tool
Jo, men givetvis finns det program även i Linux, och ett av dem är det du använder för att öppna textfiler. Exempelvis vim, less, more, emacs, nano, ... Så min fråga är helt enkelt vilken texteditor/motsvarande som visar meddelandet att svarsfilen inte är en textfil.
(För din information har föreningen runt 8 servrar som kör Linux så lite kunskap finns det.)
En ny version av Disbyt beta-testas för närvarande. I den är all text konverterad till UTF8. Som Olof påpekar är data i Disbyt från olika teckenkoder som använts under 25 års tid. Det har varit ett omfattande och komplicerat arbete att justera teckenkoden till en enhetlig standard. Inte nog med att olika bidrag kommer från olika datorer och länder över tiden. På samma rad kan olika teckentabeller förekomma som konsekvens av att bidraget bearbetats efter leveransen. Det är inte alltid som man kan urskilja vilken teckentabell som använts vid "kontrollen". Det finns heller ingen smart väg att konvertera från ursprung till UTF8. Det mesta kommer dock att visas i UTF8 men det finns säkert rader som inte funkar med den konverterare som gör jobbet. De svarsfiler som omnämns genereras i den nuvarande miljön för kontroll av bidragen och den kommer att användas ett tag till.
/Ulf A (konverterar Disbyt data till ny SQL-databas)
Är sökfunktionen i nya versionen förbättrad så den klarar den relativt vanliga varianten (tyvärr...) att man har en namnvariant inom parentes i stället för som mer brukligt (antar jag) en AKA-tag (Also Known As).
När "min" Lisa Christina Johannisdotter i böckerna ibland kallas Stina så kanns det enkelt och tydligt att ha hennes namn skrivet som Lisa Christina (Stina) Johannisdotter. Liknande för emigranter som byter efternamn, då finns det "minst använda" inom parentes.
Problemet är att om jag söker efter Lisa Christina Johannisdotter i Disbyt så hittas inte mina poster för min mormors farfars mor. Jag måste söka efter Lisa Christina (Stina) Johannisdotter för att de ska komma med (och då kommer ju inge poster från andra personer, utan (Stina), med i resultatet.
Det kan ju inte vara så att ett namn inom parentes ska vara tvingande att ha med i sökningen för att posterna ska hittas.
Att det har blivit namn inom parentes ibland är inte bara för synligheten, många program hanterar inte AKA, som väl är ett "Event" utan datum...
Förnamn och efternamn rensas på ()[] och enstaka fristående tecken ex. "f". Namnen normaliseras och resultatet läggs i ett sökfält för namn. Ditt exempel "Lisa Christina (Stina)" blir då "lisa kristina stina". Det blir träff på alla namnen enligt normaliseringen t.ex Christina som normaliserats till kristina, just nu åtta varianter christin, christina, chrestina osv. Det finns några som skrivit in förnamn "(H)Anna" och troligen avsett att detta skall vara hanna eller anna. Just nu görs ej denna tolkning utan resultatet blir hanna, dvs ( och ) tas bort. Sökfältet finns bara i bakgrunden och de inskrivna förnamnen och efternamnen visas i oförändrat skick.
Sedan måste söksträngen skrivas in så att det blir träff även på "stina". Flera metoder testas just nu för att få fram ett bra och flexibelt "namnsök".
OK, jag förstår nu. "Lisa Christina (Stina)" finns kvar för att presentera personen men för sökningens skulle blir det "lisa kristina stina". Tycker dock att en sökning efter "lisa kristina johannisdotter" borde hitta "lisa kristina stina johannisdotter".
I kommande Disbyt kommer Lisa Christina (Stina) Johannisdotter att lagras med förnamn lisa kristina stina och efternamn johannisdotter.
'Lisa Christina' och 'Johannisdotter' ger i nuvarande testdatabas 27 svar, men inte Lisa Christina (Stina).
'Lisa Christina*' och 'Johannisdotter' ger 28 svar, inklusive Lisa Christina (Stina).
'Lisa Christina *' och 'Johannisdotter' ger Lisa Christina (Stina) enbart.
Det går också att använda en ny funktion kallad bokstavssökning.
Hon kommer att visas som Lisa Christina (Stina) Johannisdotter.
Å ena sidan logiskt, å andra sidan borde "Lisa Christina Stina" och "Lisa Christina (Stina)" inte behandlas likadant. I första fallet ska en sökning på "Lisa Christina" inte hitta personen, i andra fallet ska det bli träff. Namn inom parentes ska inte ens behövs matchas med "*".Citat:
Ursprungligen postat av Gestblom
Släktforskare registrerar sina namn på olika sätt. Vad betyder ett namn inom parentes? Finns det en generell tolkning?
Jag har gått bearbetat ganska många GEDCOM filer och det verkar som om ganska många använder avskiljningstecken för att markera smeknamn eller "vardagsnamn".
Men det förekommer andra skiljetecken också, där t.ex. slash (/) är olyckligt efter som det tecknet har speciell betydelse i namnfältet för GEDCOM filer.
Själv använder jag parenteser bara när helt avvikande förnamn används, namn som inte finns i dopboken. Däremot inte för de namnförkortningarna som t.ex. Christina-Stina. Då skulle namnfälten krylla av parenteser.
Det kan också vara så att det står Christina i dopboken och Stina i en husförhörslängd. En forskare kan ha det första namnet, en annan det andra och en tredje båda och då kanske skriver Christina (Stina).
Om man inte använder bokstavsexakt sökning bör en normering behandla Christina och Stina på samma sätt.
Men det finns säkert namnvarianter som inte kan hanteras lika enkelt.
När det gäller just min Lisa Christina (Stina) så är det just så att hon i nästan alla böcker benämnts Lisa Christina men i någon Stina. Då har jag lagt in Stina inom parentes då ett tidigare program jag använde inte hanterade AKA. Nu har jag Family Tree Maker, som hanterar detta, så för henne byter jag så Stina placeras som AKA. Stina är ju dessutom en känd kortform av Christina.
Ett annat fall där jag använt parentes är "(Anna) Maria Hultin". I födelseboken står hon enbart som Maria, men på ett par ställen benämns hon Anna Maria och det är säkert samma person. Där är AKA inte lika självklart.
Problematiken är nog mera komplicerad än bara varianterna Christina och Stina. Man kan dela upp varianterna i stavningsvarianter (Kristina, Christina) och namnvarianter (Kerstin, Kristin, Stina). I detta fall är grundnamnet Kristina/Christina med en otalig mängd stavnings- och namnvarianter.
Ett annat grundnamn, Johannes, har otaliga namn- och stavningsvarianter i en mängd språk (Ioannis, Jean, Yannes osv).
Än så länge vet vi ju inte hur avancerad personsökningsalgoritmen i nya Disbyt kommer att bli men att den bör bli mycket bättre hoppas vi på. En bristfällig personsökning skapar också många onödiga dubbletter i databasen.
Nedan har jag just kopierat Christina från RGDs namndatabas för att visa hur många varianter det kan finnas:
carstina, cerstina, cherste, cherstena, cherstene, chersti, cherstin, cherstina, cherstj, chiersten, chierstena, chiersti, chierstin, chierstina, chiertsina, chiristina, chirsa, chirsta, chirstena, chirsti, chirstij, chirstin, chirstina, chirstine, chistena, chistina, chjerstena, chjersti, chjerstin, chjerstina, chreistin, chresstinna, chresta, chresten, chrestena, chrestensa, chrestenssa, chrestentza, chrestenza, chrestin, chrestina, chrestine, chrijstina, chris, chrisiana, chrisiane, chrisina, chrisjana, chrisrina, chrisstina, christ, christa, christana, christel, christella, christena, christence, christensa, christense, christenssa, christentia, christentza, christentze, christenza, christesa, christi, christiana, christiane, christiania, christianna, christianne, christijnna, christin, christina, christine, christinna, christinse, christintia, christjna, christna, christsina, christtina, chrstina, chärstina, cierstina, cirstina, cistina, crestena, crestina, cristina, cristine, ghristina, keista, kerrsti, kerst, kersta, kerstena, kerstene, kersti, kerstii, kerstin, kerstina, kerstine, kerstj, kerstn, kerstänssa, kerthina, kesrti, kesta, kieerstin, kierst, kiersta, kierste, kiersteina, kiersten, kierstena, kierstene, kierstenn, kierstenna, kiersti, kierstieena, kierstig, kierstii, kierstij, kierstijna, kierstin, kierstina, kierstine, kierstj, kierstji, kierstjna, kierstna, kierstne, kierstü, kiertina, kiestina, kiestinne, kijerstine, kijrsta, kijrstin, kijrstina, kijstin, kijstine, kiresti, kirst, kirsta, kirsten, kirstena, kirstene, kirstenna, kirstenne, kirsti, kirstij, kirstin, kirstina, kirstine, kirstinna, kirstj, kirstjn, kirstjna, kirst˙, kirtsj, kistena, kistene, kistina, kistine, kistrina, kiärsten, kiärstena, kiärsti, kiärstin, kiärstina, kiärstinna, kjerrsti, kjersta, kjerstena, kjersti, kjerstii, kjerstij, kjerstin, kjerstina, kjerstine, kjerstj, kjerstjna, kjerti, kjertin, kjertsta, kjestena, kjesti, kjestin, kjestina, kjirstina, kjrstena, kjrstj, kjärsti, kjärstin, kjärstina, krestena, krestensa, krestin, krestina, kristalia, kristantia, kristena, kristendza, kristensa, kristenssa, kristi, kristiana, kristiane, kristin, kristina, kristine, kristj, kristna, kritala, kyrstin, kärsta, kärstena, kärsti, kärstin, kärstina, körsta, stijna, stina, stine, stinna, titine, titti, tittie, tjerstena, xstina,
Det problemet jag tar upp rör egentligen inte namnvarianter, utan det att parenteser bara tas bort och namnet som stod inom parentes behandlas likadant som övriga namn.
De som "vet" att Lisa Christina enbart hade dessa namn söker inte efter "Lisa Christina*" och missar därför Lisa Christina (Stina) i sökningen. För att det ska fungera bra i Disbyt med namn inom parentes måste antingen dessa namn markeras som "optional"/"valfria" och inte krävas för matchning - även utan "*" - alternativt tas alla namn inom parentes helt bort från sökningen och sparas enbart för presentationen. Som det är nu blir det mest fel med parentesnamnen.
Visst har jag förstått ursprungsfrågan men jag ville utvidga den något. Det kanske står en annan stavningsvariant i exempelvis födelseboken, som du normerat till Christina, eller att det för Lisa står Elisabet. Det är inte bara frågan hur parenteserna skalas bort, som avgör, om det blir träff eller inte. Om man går säg 200 år tillbaka, så kan floran av använda namn-/stavningsvarianter för en och samma person vara rätt omfattande. En annan fråga är ju också om det måste vara träff på alla tre namnen eller enbart ett av dem för att ge respons i Disbyt-sökningen.
Funktionen Bokstavssökning i kommande Disbyt:
Skriv Johanniesdotter eller johannesdotter i fältet för efternamn.
Aktivera bokstavssökning för förnamn och skriv lisa kri
Tre varianter presenteras: eva lisa kristina, lisa kristina och lisa kristina stina.
Dessa täcker alla personer som finns med lisa kristina i den ordningen.
Vi diskuterar andra sökmetoder som kan komma till senare.
Kanske algoritmerna från RGD:s dubblettsök kan få användas, sortering i ordning efter matchningskvalitet.
Hoppas att även sökning på exempelvis Wahlström, kan ge träff på stavningen Valström - typ.
Åtminstone att skillnad inte görs på W och V.
Finns ju på en del söksajter inställning av exakt och ungefär mm.