* Non-English sentences

[JoopvB]

As an abandoned TMG castaway I have been searching for good alternatives and my top 2 list now is Family Historian and Roots magic (in that order). There is one thing to make FH the ideal choice and that is a little help with the narrative sentences. I'll gladly translate all the sentences I need to Dutch (most of my reports are for Dutch users) but I need some help from the FH programmers with built in constructs like he, she, him, her etc. (and a little extra flexibility in presenting dates, as well as prefixes for place names).

I am aware that a request like this has been put forward before (supported bij Jane!!) and got no votes. But... I'd like to suggest that in this specific case the democracy of a voting mechanism works against expanding the reach of a great product. Indeed, if your market is English, no one is very much interested in this kind of features. If on the other hand your market is "the world" (or at least some part of the continent at the other side of the English Canal) then please reconsider.

Anyway, if you've read up until here, thanks for doing so and if you would put my wish on a notable position on the wish list, you have made this TMG castaway a very happy FH evangelist.

Thanks, Joop

[tatewise]

Welcome to the FHUG Joop.
I have moved this to the General Usage Forum until established that Sentence Templates really cannot do what you want. The New Wish List Requests Forum should only be a last resort.

The new V6 features the programmers have added to the Sentence Templates may get close to what you need.

They now allow Functions that can test the Gender (SEX tag) and produce hij or zij.
e.g.
{=TextIf( FieldText( GetRecord(), 'INDI.SEX' ) = "Male", "hij", "zij" )}

That works as FieldText( GetRecord(), 'INDI.SEX' ) returns either "Male" or "Female".
So FieldText( GetRecord(), 'INDI.SEX' ) = "Male" is either true or false.
The TextIf() function returns "hij" if true or "zij" if false.

You would use that instead of code {individual} in most Sentence Templates except probably the Birth Event because that usually comes first and needs the Individual's name.

Similar functions can be used for hem & haar and for zijn & haar in place of codes {him/her} and {his/her}.

You will have to be more specific about "extra flexibility in presenting dates, as well as prefixes for place names" for us to help you.

[JoopvB]

Hi Mike,

Thanks for your prompt reply and suggestions. The use of functions might indeed help me out in most situations; nevertheless keeping it on the (right) list as something to have as an option to make it easily accessible for everybody seems a good thing.

The dates in Holland don't start with a capital (not for the day and not for the (abbreviated) month)). So an extra preference option somewhere to select such a format is what I meant.

The prefix for a place name in Holland can be "te" (if only a place name) or "in" (if detail field, place name). This is what I meant with the Place Prefix question.

Altogether my guess is that FM could come a long way to open up for other languages by supporting some of these options as a preference setting and use motivated translators to produce sentences in whatever language and make them available for import.

[tatewise]

The =ToLower() function should help with Dates.
e.g.
{=ToLower(%FACT.DATE:DAY_OF_WEEK%)}
{=ToLower(%FACT.DATE:COMPACT%)}

I still don't understand the criteria for the Place prefix.
How does FH differentiate only a place name from detail field, place name?

By detail field do you mean Address field?
And place name is I guess the Place field?

If the functions can produce a workable solution, then a Dutch (or other language) Fact Set could be posted in the fhugdownloads:factsets|> Downloads and Links ~ Fact Sets for everyone to use.

Wish List Ref 152 Ability to translate all labels in reports into other languages had few votes and was CLOSED because alternative solution proposed:
The suggestion was made (by Jane) that
a) fact sets could be set up and
b) output could be run through one of the online translate engines.

A similar topic was discussed here:
Hebrew Language Support (9790)
Narrative reports - changing language (8127)

[JoopvB]

Thanks Mike, you've given me a lot to process. It seems that your solutions may go a long way to helping me out. I'll be back with the results (or more questions if I get stuck ).

About the place: details is a TMG word and it means anything within a "place" (village, town, etc.); could be a street address, a church, a building etc.

Just to expand on the place concept a bit more (especially in relation to FH). Genealogy is all about What, When and Where. What is covered in most software to a great extend by a diversity of facts (FH word). When has also been given a lot of attention by support of all kind of calendars, date ranges, "about dates" and what have you. But Where still seems to lag behind and I think it shouldn't be and need not be. Today with geo location we can know where Where was (as close as the source helps us out); let's call that "the location". So the only extra thing we need is the name (description) that was used at that time (by those people) to reference to that location. Another source for that same location might use a different name or even name structure (e.g. same name within a different county). And even nowadays (modern times!) it is very well possible that a location name you entered 10 years ago is not relevant anymore due to (administrative) reshuffling of villages, towns etc.

So, what I do is just record what I find: details - place field 1, town or something like that - place field 2, some kind of grouping (if specified) - place field 3, country (if specified) - place field 4. I've never seen a place specified in a source with more levels of information than this (and I've certainly seen my share of sources in the last 20 years or so). Important is now to add two extra actions: a) geo-map the location as best as you can; b) give it "modern name" for easy reference (if different from the specified name); FH 6 supports this!

All this as it may be, I still would like extra support for places/locations in the software. For research, locations can help you out by e.g. using the neighbours as a reference, or by the description of the object (house, land etc.). Extension of the location information in FH would help a lot. Think of: introducing the concept of an object (on that location), defining properties of that object, relation between an object and witnesses (neighbours at that moment in time) and last but not least link media to the object to support great reports. One might even consider genealogies of object like famous buildings, churches, mills etc.

It may not be that the above is straightforward GEDCOM x.x, but sometimes we have to use new facilities (like geo coding) and work from there and who knows that it (in time ) might become GEDCOM y.y.

Thanks for reading (if you made it up to here) and if the above gets some support from people it might even become part of FH 7?

[tatewise]

I have added some revised details to my previous posting.

You last point about 'locations' has beed discussed at length in other postings, but seems to have gone off the topic of Non-English Sentence Templates and how to decide when to use te and when to use in as a Dutch prefix to place names.

[JoopvB]

You're right, I got carried away...

[JoopvB]

Hi Mike

Returning to the topic of non-English sentences after a few days of trying to get a comprehensive set of Dutch sentences.

To start with my conclusion: I regard it as impossible to build a fact set for another language (e.g. Dutch) without a set of built in features in FH.

Reasons:
1. Even the most simple sentences become overly complicated by using data references and functions to just do a translation. Example, I used your solution to translate he/she into hij/zij. It works, but not everywhere and not in every context (as the default English version will).

2. Important features seem to be automatic, e.g. suppose someone lives somewhere "from 15-03-1900" which in Dutch would be something like "na 15-03-100". And this is only one of the date modifiers! No idea how to...

3. Days of the week, names of the month etc. are not easily translated as well.

4. ...

It's a pity that a product (FH) that has so much potential (I have become to really like all the features) and that outranks (in my humble opinion) Rootsmagic, Legacy and some of the other "top" software, should be supporting English sentences only. By nature genealogy is international; people migrate and so supporting a sentence language other than English is - I think - a must.

We don't need a translation of the FH software (English is fine), but we need the right tools to be able to output genealogy results in a language of choice. And, I'm sure that a substantial number of Dutch, Belgium, French, Spanish and German (to name only a few) users are to be found to do the necessary translations. We just need the tools.

Mike, you being a seasoned insider... what is the best way to get this on the software developers todo list? Do we need a business case, crowd support, market research...

[tatewise]

I sympathise with your conclusions. The Fact Set approach would seem to be too challenging, but I thought it worthwhile exploring.

Referring back to my 02 May 9pm posting, that was Jane's option a) but option b) was to use one of the many translation tools on the saved report.

The fact that the Wish List item got few votes suggests there is not much market demand. Certainly the topic rarely appears in these Forums. I suggest you E-mail Calico Pie and see how they respond. My guess is that the effort needed to translate all sentence structures into many languages (needing language experts to be hired) is unlikely to be rewarded by many extra product sales. Sorry! However, I may be wrong.

[JoopvB]

Well I've gone back to English and indeed, the best thing might be to send an email to Calico Pie.

a) Translating a report is an option, but it is at the very end my my option list (it's 2015!)

b) The low number of votes is easily explained; all the users are English speakers, so they have no priority on sentences in non-English languages. But then again if Apple had used a voting system, we wouldn't have an iPhone now.

c) My suggestion is NOT to have Calico Pie hire translators! What we need is no more (and no less) than making options available in the tool set to fully and easily implement non-English fact sets. This is in, my humble opinion, not a giant task; we already have fact sets (so 90% of the work is already done); now just add the features to make it 100%. The rest of the work can be done by users of the product. I, for instance, would gladly be of help in creating a Dutch set and I'm sure the same is true for other non-English users. The product FH6 is worth it!

Cheers, Joop

[tatewise]

I have moved this back to the New Wish List Requests Forum.

I suggest Wish List Ref 152 Ability to translate all labels in reports into other languages is re-opened for a number of reasons:

1. This thread has explored the Fact Sets suggestion, and despite Sentence Functions, has proved to be virtually impossible.
2. Online translation is a possibility, but customisable Sentence Codes would be much better.
3. With the introduction of Unicode in V6, I suspect there will be more interest now.
4. Related topics include Hebrew Language Support (9790) and Narrative reports - changing language (8127).

[JoopvB]

Thanks Mike, in the mean time I did as you suggested and mailed Calico Pie with my suggestions.

This is Simon's reply:

Hi Joop - thank you for your email. The short answer is that we strongly agree with you. Supporting multi-language output is something we very much want to do. It's been high on our priority list for some time, but somehow never quite made it. However, now that we have finally implemented Unicode (which was deemed a higher priority) I'm hoping that that multi-language output's time has finally come. No promises or dates though (we don't do that).

Thank you also for your ideas and offer of help. I have made a note of your name and email address and will very probably take you up on that, closer to the time.

Simon Orde

So I guess even if we're not yet on the same page, I'd say we're at least in the same book.

[tatewise]

That does sound promising.

[Preb57]

Hi,

I fully support that Non-English should be possible. I would like to use Danish. As I see it we do not as much need a translation as a file with the external (report, diagram and data) texts that we could then translate or adjust. This would also give English-speakers the possibility to ad their own flavour to reports.

I do not as such need a translation of the user-intereface, but of course if Calico Pie would supply a file with the texts we could translate them as needed.

I have asked Calico Pie in an email an they suggested using functions etc as in this thread, but they state that

This is an area we hope to address in more detail in a future release, but we do not currently have a time scale for doing so.

Let's hope we can convince them to move this up the priority list and time scale.

[JoopvB]

Yes, the user interface in English is no problem. And as I suggested before, the use of a custom fact set for the translated sentences comes a long way (I have already my own custom set for Dutch). The only extra thing needed is an option/preference to be able to choose for language dependent standard generated words like he/she/his/her etc. and date and place prefixes.

So in my view, not really a big change in the product but one I would be very happy with.

[tatewise]

Wish List item Ref 541 Narrative Sentence options for other languages has been created.