Gebruik van Cédille ç in naam François dan zie je in Genealogie Online het bovenstaande. Sinds vandaag gebruik ik voor publicatie Gedcom 7.0, maar daarmee schijnt dit probleem niet mee opgelost te zijn. 

Evenals voor plaatsnamen als: 's-Hertogenbosch, 's-Graveland, 's-Gravenhage, komt het als bovenstaande in GenealogieOnline in beeld.

Hoe los ik dit op?

Ik gebruik Reunion (Mac).

Ik zie graag uw reacties tegemoet.

Dag Eize,

Het probleem zit bij het programma waarmee je het GedCom bestand aanmaakt. Als je daar de Character Set UTF-8 gebruikt, moeten alle vreemde tekens, inclusief Japans, Russisch, of wat dan ook, opgelost zijn. Dus ook een ç (cedille).

Michaël

Bedankt voor de reactie. De genoemde instelling gebruik ik al, ook bij de vorige Gedcom 5.5.1. Ik hoopte dat dit met Gedcom 7.0 opgelost zou zijn. Vandaar dat ik ten laatste leste mijn 'probleem' in dit forum plaats.

Ik wacht de overige reacties nog af. Wellicht is het iets anders...?

Op zich zou dit gewoon met GEDCOM 5.5.1 moeten kunnen, als je daarbij ook kiest voor UTF-8.

Je zou ter controle het GEDCOM-bestand ook in een tekst editor kunnen laden, want die moet de cedille dan ook laten zien.

Bedankt voor je reactie. Dat was precies de situatie voordat ik GEDCOM 7.0 kon gebruiken. Ook met GEDCOM 7.0 is dit probleem niet opgelost. De vraag is wat kan/moet ik doen om dit vanuit Reunion te kunnen regelen dat alles wat geschreven is in de publicatie ongeschonden over te laten komen. 

De weergave van zgn diakrieten bij GO is een steeds terugkomende vraag/melding/probleem vanaf ca 2010.
Zoals dhr. Scholl in zijn bericht van 30 juni 2024 terecht opmerkt: … Diakrieten gaan bij GOline inderdaad niet altijd goed …(einde citaat). 
Ook niet als een gedcom wordt aangeleverd in UTF-8. Weet niet of het bij alle diakrieten verkeerd gaat.
Vermeldenswaard is dat de c-cedille bij een gedcom export van Reunion op de correcte wijze wordt weergegeven. Het is derhalve zeer waarschijnlijk dat de oorzaak ligt bij GO en/of de gebruikte browser.
Wat ik mij afvraag of de 'zeer aparte weergave' van de apostrophe vóór de plaatsnaam te maken heeft met de instelling ’thumb’ of smart quotes’, zowel de instelling bij Reunion als de instelling op de Mac.

Mogelijk kan dhr. van der Velden mij hierover informeren in een prive mailtje

Frans van Bodegom
Reunion NL Support Team

Ik heb net een test gedaan met een nieuw bestand. Ik had een handvol Francois' en Francoises, zonder cedille dus, en dit was een mooie aanleiding om daar wat aan te doen, met dit als resultaat:

https://www.genealogieonline.nl/stamboom-borgsteede/I3694.php

En als ik naar het voorbeeld van Eize kijk, gaat het daar fout, ook bij het zoeken naar personen, waarbij de smart quotes geen rol spelen.

Gramps exporteert standaard UTF-8, en GEDCOM 5.5.1:

1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8

En deze persoon staat als volgt in mijn GEDCOM-bestand:

0 @I3694@ INDI
1 NAME François /van Havre/

En dat laat mij vermoeden dat het probleem toch in het bestand van Reunion zit.

Ben het niet met u eens.
Mijn verwijzing naar 'dumb' en 'smart quotes' heeft betrekking op de apostroph voor de plaatsnaam en niet op de c-cedille. 
Zie de screendumps van zowel gedcom 5.5.1 en gedcom 7, waarbij de c-cedille correct wordt weergegeven
In een eerder 'draadjes' heb ik gewezen op het feit dat zowel MacFamilyTree, Heredis, Reunion maar ook Gramps, draaiend op een Mac pro 
 dergelijke problemen geeft. 
(https://www.stamboomforum.nl/subfora/45/2/43432/0)
https://www.stamboomforum.nl/subfora/4/2/57098/0
https://www.stamboomforum.nl/subfora/45/2/56606/0

Als dit zo is, dan zou het betekenen dat een GEDCOM-bestand dat je op een Mac maakt inhoudelijk niet gelijkwaardig is aan een soortgelijk bestand zoals ik dat vandaag op mijn PC, in Linux, heb gemaakt. En dan is daarbij tegelijk ook de vraag in welk opzicht dat dan anders is, en daarvoor zou je dan de bestanden naast elkaar moeten kunnen leggen.

Ik zie mijn eigen naam ook staan, in die 1e draad, en Louk Box is met zijn MacBook (met Gramps) ook een keer hier op bezoek geweest.

Zou je mij een voorbeeld kunnen sturen van zo'n bestand? Het feit dat het met 4 verschillende programma's, inclusief Gramps, niet goed gaat, lijkt namelijk op een dieper liggend probleem te wijzen, waar ik op dit moment alleen maar naar kan raden, omdat ik zelf geen Mac hardware heb.

Eize, ben je bereid om naast Reunion een keer met een ander programma te experimenteren, zoals Gramps of RootsMagic? Ze draaien beide ook op MacOS, en ik ben wel benieuwd hoe de namen overkomen als je een GEDCOM-bestand van Reunion in 1 van deze programma's importeert. En als dat goed gaat, wordt het ook interessant om te zien hoe het gaat als je vanuit dat programma een GEDCOM-bestand maakt, en dat hier op de site publiceert.

Ik werk zelf met beide op Linux, en Windows, en voor de Mac-versies kan je hier kijken:

https://www.gramps-project.org/wiki/index.php/Nl:Download#Mac_OS_X

https://rootsmagic.com/Try/RootsMagic/

Gramps is echt gratis, en RootsMagic Essentials kan je zonder tijdslimiet gratis proberen, met wat beperkingen. Maar die zitten voor een test als die ik nu voorstel niet in de weg.

Voor zover ik nu weet, kan je als uploader niet veel doen, omdat Genealogie Online zich in de bestanden verslikt, ook als je die als UTF-8 exporteert. Ik heb dat getest met de heer Van Bodegom, die mijn werkbestand in 5 verschillende indelingen geexporteerd heeft, en weer naar mij heeft gemaild, zodat ik daarmee mijn publicatie kon verversen, en ook mijn aanknopingspunten kon behouden.

En daarbij is de conclusie, dat het in geen van die indelingen, waarbij MS-DOS is overgeslagen, echt goed gaat. En dat is bij indelingen als ANSEL (verouderd), Macintosh en Windows (niet echt standaard), wel te verwachten, maar bij Unicode en UTF-8 zou het wel goed moeten gaan, en dat doet het ook niet. En ik zie bij Unicode exact dezelfde fout als in het plaatje aan het begin van deze draad.

Als ik deze laatste bestanden, die dus door Reunion heen zijn geweest, in Gramps importeer, blijkt de codering wel goed te zijn, in die zin, dat ik alle tekens zie zoals ze bedoeld zijn, inclusief de smart quotes. En als ik een daarvan dan zelf publiceer, uit Gramps dus, verschijnt dat bestand ook goed op de site.

De reden waarom het bij mij goed gaat, met Gramps dus, en niet direct uit Reunion, lijkt te zitten in de regeleinden, want die zijn bij Mac anders dan bij Linux, wat ik gebruik, en ook anders dan Windows, wat ook weer van Linux verschilt. En het lijkt erop, dat de site door dat verschil ook de tekenset niet begrijpt, terwijl die wel goed is. Als die niet goed was, zouden de bestanden namelijk ook niet goed in Gramps verschijnen, of in RootsMagic, dat ik ook vaak gebruk in combinatie met Ancestry en FamilySearch.

Buiten de regeleinden zie ik verder geen verschil.

Het is goed te vernemen dat dhr. Borgsteede zich zo heeft ingezet om de oorzaak op te sporen. Het sluit naadloos aan  bij mijn conclusie uit een draadje uit 2016. Het is nu aan dhr Coret om het Mac diakrieten probleem (dat al gesignaleerd is rond 2013 en met enige regelmaat gemeld wordt) op te lossen. Mogelijk zijn er Mac gebruikers die hun bestanden uploaden naar Geneanet. Ben benieuwd of daar hetzelfde diakrieten probleem ook bestaat.

Ik heb die test even gedaan, bij Ancestry, en bij Geneanet, en alles gaat goed, ook met smart quotes.

Dhr. Borgsteede en ik zijn bezig een 'workaround' te testen. 
Nadere communicatie volgt en zal (als dit goed werkt) een FAQ maken op de site van Reunion-CQ Software. 

En ik kan nu melden dat het experiment is geslaagd:

https://www.genealogieonline.nl/stamboom-borgsteede/I12283.php

Daar ben ik ook benieuwd naar, die andere gebruikers, en daarbij zijn de signalen die ik zie nogal wisselend.

De vier Mac gebruikers (die mij bekend zijn) die problemen hebben/hadden met diacrieten bij GO hebben van mij een 'Concept FAQ Diakrieten' ontvangen (met een 'Workaround'). 
Deze zal binnenkort ook geplaatst worden bij de FAQ van CQ Software: https://www.cq-software.nl/gebruikersvragen-faq-r13/

Frans van Bodegom
Reunion NL Support Team