In individual.htm there is a line at the start:

You have to create a little method like that:

If you want to translate the name from one language to another, you will need to use the "NameDictionary.xml", to extract first and last name.

I guess that one of the ways will be to use the dictinary.xml for this purpose like all the phrases "PhBirth" and "PhParents" and so on.

Can you give a few examples?  I can think of a solution only if I have a few examples...

Each type of name (especially given ones) should include - in fact - at least a pair of fields:

1st one for Latin transcription

2nd one for native transcription:

3rd,4th,... one for additional translation(s) of the name 

As a result, even  should be able to understand them ...  

I disagree. This is why we came up with the NameDictionary.xml file to translate names to other languages than the one in the tree. Dan is already working on a tool to manage this file.

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:

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.

Lets finish ver 2 first

I will get back with the report generator to improve it after version 2.0.  I understand the report generator is not finished yet, however it is usable.  I am happy the report generator is working at all, because this was brand new technology to me.  I have many ideas to make the report generator more powerful and than it is now. 

I am thinking of adding the attribute Language to each elemen in Config.xml, so the report generator can pick the file "homeJA.htm" or "homeHE.htm" when generating the report.  If there is more HTML code, it will be easier to have a different HTML file for each language, than moving everything in the dictionary file.

At the moment, I am working on Bet15 for the social entities.  I use the name "Social Entity" to describe a school, church, club, committee, council, advisory group, organization, partnership, business or corporation.  Then, there are "Social Activities" and "Social Relationships" such as managing, funding, investing, coaching, customer of, associate, partnership, and more.

update: lang.vbs not needed anymore