921, 922, 923: Support (French)

[Da Vinci]

Hi,

First of all, I would like to congratulate you about your software. It deserves to be a lot more known. It is easy and pleasant to use. It is also the best I know to make quick changes on many individuals in a family bank.

Nevertheless, I would like to humbly suggest you some improvements.

The french translation of your software is excellent altough:

1) The french translation of 'ABT' or 'About' is not 'Par exemple' but 'Environ'. It is annoying.

2) Translating 'ABT', 'BEF' and 'AFT' and adding the translation in the GEDCOM file is not a desirable thing because it is not part of the Gedcom standard and it is not accepted by most software.
A solution would be to display the choices ABT BEF and AFT, translated if you wish, with selection boxes. But in the database, the standard 'ABT', 'AFT' and 'BEF' would be written.
Another solution is simply to do nothing about those word (let them in their native state).

3) For GEDCOM file compatibility, it should be possible to dynamically change the date formats, not only when import importing Gedcom, but also when exporting it. Also be able to make the changes in the database loaded in the software. Date formats:

YYYY / MM / DD or DD / MM / YYYY or DD MMM YYYY (example: 01 MAY 1858 - the most common and important format!)
YYYY-MM-DD or DD-MM-YYYY

4) Now for the funeral only the city can be shown. It would be desirable to indicate the precise location (the name of the cemetery, a place known or GPS coordinates) Burial Date Religion - place (cemetery) - City

5) For weddings:
It would also be interesting to indicate the marriage contracts:
the date, place and name of the notary. I losted them when I imported my GEDCOM.

6) Management of cities:
It would be interesting to manage cities as individuals. Have records of cities, their coordinates GSP (Google Map compatible), and comments.
Because there are many errors in the records about the city name (some cities vanished, other changed names or merged with one or more nearby cities, etc). Thus we could correct all errors related to a city name in only one operation. Also add informations or comments about the history of this city. All this is accessible from the records of each individual who relate to that city.

You have all my admiration and respect,
God bless you.

Da Vinci.


-------------------------------------
#Wunschliste_921_OFFEN
#Wunschliste_922_OFFEN

[Marcus]

Sorry for the late answer, but it was just too much for a quick reply.

1) The french translation of 'ABT' or 'About' is not 'Par exemple' but 'Environ'. It is annoying.

I wasn't able to detect that string. Where do we have to change it?

2) Translating 'ABT', 'BEF' and 'AFT' and adding the translation in the GEDCOM file is not a desirable thing because it is not part of the Gedcom standard and it is not accepted by most software.
A solution would be to display the choices ABT BEF and AFT, translated if you wish, with selection boxes. But in the database, the standard 'ABT', 'AFT' and 'BEF' would be written.
Another solution is simply to do nothing about those word (let them in their native state).

Ahnenblatt is doing just that! Whatever you write in the Date-Fields is saved in your Gedcom-File - there is no automated translating.

3) For GEDCOM file compatibility, it should be possible to dynamically change the date formats, not only when import importing Gedcom, but also when exporting it. Also be able to make the changes in the database loaded in the software. Date formats:

YYYY / MM / DD or DD / MM / YYYY or DD MMM YYYY (example: 01 MAY 1858 - the most common and important format!)
YYYY-MM-DD or DD-MM-YYYY

Will be added as a new wish to the 'wish-list'

4) Now for the funeral only the city can be shown. It would be desirable to indicate the precise location (the name of the cemetery, a place known or GPS coordinates) Burial Date Religion - place (cemetery) - City

You can already write more than just the name in the respective fields. However in the next major release it will be possible to add almost any thinkable field: Ahnenblatt 3.0 - Preview

5) For weddings:
It would also be interesting to indicate the marriage contracts:
the date, place and name of the notary. I losted them when I imported my GEDCOM.

Though Ahnenblatt has not an own field for these informations, nothing should get lost durin Import. You can add any 'unknown' information in the "notes" or "sources" sections.

6) Management of cities:
It would be interesting to manage cities as individuals. Have records of cities, their coordinates GSP (Google Map compatible), and comments.
Because there are many errors in the records about the city name (some cities vanished, other changed names or merged with one or more nearby cities, etc). Thus we could correct all errors related to a city name in only one operation. Also add informations or comments about the history of this city. All this is accessible from the records of each individual who relate to that city.

You can correct wrong names through the "search and replace" in one step.
A tool/area where you can manage the places in the way you mentioned is already part of the 'wish-list'
Marcus

[DaVinci]

Hi.

Thanks for answering.

To be clear:

The first two points, 1 and 2, are related to GEDCOM import when using Ahnenblatt v. 2.62 with the french interface (I am using it under Windows Vista Premium).

Each time a GEDCOM is imported:

BEF is changed in 'en avant BEF' (The correct translation is 'avant')
AFT is changed in 'après' (The translation is correct)
ABT is changed in 'par exemple ABT' (The correct translation is 'environ')

The date format is converted by defaut to the international format, meaning: YYYY/MM/DD

I verified with a text editor before the importation and after the exportation and there is no doubt in my mind.

I think there should be no change of those terms because there are part of the standard gedcom. The translation of those terms and the conversion of the date in the international format, make the gedcom incompatible for a lot of softwares. Maybe the translation/conversion should be offered as an option.

Point 4:

I am very glad to heard about those new field possibilities, and I am sure that it will add a lot to the versatility of Ahnenblatt. But please consider the dumb users, that maybe I am part of, that need some guidance.

Point 5:

I still think that there should be a place for marriage contracts, along/near religious mariage.

And for the lost of information, you are surely right. I verified and realized that the lost of informations occured while exporting from another software, therefore the other software is bugged, sorry.

The more I use Ahnenblatt, the more I appreciate and like it.

Respecfully,

Da Vinci

[Roger Paini]

Hi all

I could reproduce the issues DaVinci described.
- I've launched AB, language set to german
- I've created an ahn file with 3 persons where the tags BEF ABT and AFT were used
- I've saved the file then as gedcom file

- I've closed AB, started it again and changed the language to french
- I've then loaded the gedcom file

-> Now the translation issues DaVinci described are visible

After that I've saved the opened gedcom file as another gedcom file and compared them. The special tags were doubled.

With regard to the date format - if you go to Fichier -> Propriétés -> Format de date, does changing that format before opening the data file solve your problems?

Cheers
Roger

[Marcus]

I've tested it too, but didn't get back here earlier

-> Now the translation issues DaVinci described are visible

There are bugs, but they are a little bit different as described by daVinci. The (german) Gedcom-export is fine - german "nach" gets saved as "AFT". The translation starting with the import is correct ("AFT" is translated in "aprés") and helpful in the sene, that these Gedcom-Texts get translated.
However, "en avant" (it's not "en avant BEF"!) should be change to "avant" and "par exemple" (for "ABT") to "eviron".

In the french Gedcom-export the texts "BEF" and "ABT" get doubled here too but not "AFT"! It looks as if the 'two words' (in the tranlated strings) are part or even origin of the problem. Maybe if these are corrected, the rest will work too.
Marcus


--------------------------------
#Wunschliste_923_OFFEN

[Marcus]

The date format is converted by defaut to the international format, meaning: YYYY/MM/DD

Since I use only the DD.MM.YYYY format I've never had problems with other formats. All dates are exported like: "27 OCT 2010".
As I assume there are only problems when more than 1 format is used (or expected).
When I change my format to YYYY-MM-DD the export looks like this: "27.10.2010" which is 'correct when you understand that the date-field in Ahnenblatt is actually not a date but a text-field!! You can just write there anything you like! Unfortunately when you export data, Ahnenblatt can not decide if you want to 'keep your strings' or just want a date converted.
If I change the date to 2010-10-27 then it get's exported as "27 OCT 2010". The user has to take care, that he uses just one format in the data-basis and the file-properties.
If you do so, the "Plausibility check" ("Contrôle de resemblance") helps to find incorrect dates.

Point 4:

I am very glad to heard about those new field possibilities, and I am sure that it will add a lot to the versatility of Ahnenblatt. But please consider the dumb users, that maybe I am part of, that need some guidance.

I'm sure that we won't get lost in a jungle of options (like in a lot of other software) when there are new fields. Dirk is well aware, that the user-friendly way to get your family-data in Ahnenblatt is one of it's absolutely strengths!
Marcus