A japanese will write in japanese characters right from the beginning into the proper fields, whether it is a name, a place or a comment or whatsoever, as long it is possible. Since the report generator does not translate comments, he expects to display everything what he wrote in the same language. If he has relatives in a foreign country he might use some fields (like alternative name or nickname) for english names. A translation of a name is not likely, since the same name when used the alphabet will not always be the same when using japanese characters. Since I am a foreigner living in Japan I had to make another genofile with japanese members only. I will not use the Name dictionary, although I think it is a good idea when there is no doubt about the outcome of that translation. To have both languages in the same field will not work because of the narrative style. Of course I can have a genomap within my german genomaps to include japanese characters for names, but the main purpose is for the display in the grafik, not for the report. Because once I start using japanese names also for places I think it will not be accepted by my german relatives. So I realy have to separate both languages.

Both the Hebrew and Yiddish names need Hebrew transcriptions such as

HEB(Tzvi-Hirsch צבי-הירש)=YID(Hersch הרש).

In English he becomes ENG(Harry), in French - FRE(Henry), in Romanian - ROM(Horia) and in German - GER(Hermann).

By the way, what about my son, whose name is ... Shika-san ?

(And, by the way, it's totally unpredictable each member of my family - in which language or transcription would be interested).

;)Alex

Both the Hebrew and Yiddish names need Hebrew transcriptions such as

HEB(Zeev זאב)=YID(Wolf וולף).

In English he becomes ENG(William), in Romanian - ROM(Lupu), in Italian - ITA(Lupo) and in German - GER(Wolf or Wilhelm).

(And, by the way, it's totally unpredictable each member of my family - in which language or transcription would be interested).

;)Alex

In this case the Hebrew name needs Hebrew transcription such as

HEB('Ako עכו)=ENG(Acre)

(And, by the way, it's totally unpredictable each member of my family - in which language or transcription would be interested).

;)Alex

To the line:

<N EN="Yehuda" HE="יהודה" />

you can add as many languages you want.

I have been thinking of a solution for supporting multiple languages per comment.  GenoPro can recognize a the language code (EN, FR, JA, HE) at the end of each field such as i.birth.comment.EN, i.birth.comment.FR, i.birth.comment.JA, i.birth.comment.HE.  When generating the report, GenoPro can select the proper language code.  If no text is found under the given language code, GenoPro could optionally select the neutral language if any (eg: i.birth.comment).

On the graphical interface, a drop-down list would be available to the user to add a new comment in a new language.  Internally, GenoPro would use a clever mechanism to store and classify text for each language.

This way, there would be no need to have two trees. A single .gno file could store as many languages as necessary.  The Table Layout would have problems to display the same comment in multiple languages, so I am thinking the Table Layout should display one language (the language selected by the user).

There is also a discussion for descriptions in multiple languages.

Since translation of comments is a big problem, why not making it possible to write comments on genopro in 2 languages manually, and the report generator will use the relevant comment depending the language that the user choose to create a report

That is the goal, except the solution I am thinking allows multiple languages instead of 2.  GenoPro will not attempt to translate comments (because it is nearly impossible to do so), but will allow the same comment to be written into multiple languages.

That sounds like a grea idea. Can't this be the solution for all the fields? Can't GenoPro work in the same way in all the other fields in the gno file?

This solution could would work for any text field.  I have to figure out a good user-interface for a single-line field but it can be done.  By the way, this feature will be for version 3.0.