Multiple Languages

[Mantic Cow]

Hi - I'm working on an FM9 DB which has 2 layouts for most tables - one in English and the other in Welsh. Each table records both the English and Welsh field contents (Town_English, Town_Welsh, etc)

For example, a Welsh user views the Welsh layout and corresponding Welsh fields, whereas an English user would see the English layout and only the English fields.

My problem is that since this is a multi-cultural DB, if one user changes the Welsh Town field (for example), the DB needs to change the English Town field accordingly (ie the Welsh name for the Town is entered, and a case statement calculates what the English equivalent is and changes the English Town field to hold the English version of the town).

How can I have one calculated field overruling another? I've got ScriptFire but can't work out the neatest, easiest way of implementing such a system without major changes.

Any thoughts? Cheers guys : )

[Søren Dyhr]

Here's something to go on:

http://www.databasepros.com/FMPro?-DB=resources.fp5&-lay=cgi&-format=list.html&-FIND=+&resource_id=DBPros000489

...eventhough it's in an earlier format, would you discover how you localise the interface via Case( statements not only in the validations as the template shows...

Next thing to investigate is GetField( ....

--sd

[comment]

I don't see any connection (except perhaps Pavlovian) between that file and the question. I believe something like this could be relevant here, after necessary adaptation:

http://fmforums.com/forum/showpost.php?post/234503/

[Mantic Cow]

Hi guys.

Well a couple of interesting points but neither matches what I'm after. Labelling of fields is not a problem - I've got the layouts all sorted.

The problem is I have two fields : TownWelsh and Town English. The former records the Welsh version of the town name and the latter records the English version of the town name.

If a layout shows one of the fields (based upon the user's language preferences), how can one field overwrite the other since both need to be calculations? To put it another way, if an English user sees the TownEnglish field and changes it to "Cardiff", then a Welsh user (who views the TownWelsh field) should see the Welsh alternative (in this case "Caerdydd"). And if the name doesn't have a translation that is recognised by the DB, it uses whatever is entered by the user for BOTH fields.

Both fields need to be calculations, which can't reference each other in any sensible way .....

Obviously I have more than just one field that requires translating (TownEnglish / TownWelsh are just two examples).

[comment]

You're not (hopefully) talking about a translation - you are speaking about a lookup. This shouldn't be done by a calculation storing mountains of data, but by a relationship to a table.

If you take a closer look at my file, you'll see that the labels are actually fields. It's not the actual implementation that is important here, but the method - it can be adapted to data just as well as to labels.

[Mantic Cow]

Yes, I saw the fields as labels but (I'm sorry) I fail to see how this helps me out. I'll try and put it another way.

The logic behind it is that if a user changes FieldOne (eg NameofTowninWelsh) then alter FieldTwo (eg NameofTowninEnglish). If user changes FieldTwo then change FieldOne.

In another way : I have two layouts that reference the same table, they're almost identical but one is in English and the other in Welsh (not just the field headings but also the fields themselves). Some of the fields are the same but some are language specific. For example, there are two fields for Town - one needs to store the Welsh name of the town and the other field needs to store the English equivalent for the town name. Both these fields need to be straight text. If the user is viewing the Welsh version of the layout, then any changes they make need to be reflected in the English equivalents of the fields. The administrators have the ability to make a list of recognised towns in Welsh and the corresponding English version. When the Welsh Town name is changed, the calculation checks the Welsh Town list to see if the new Town name is listed - if it is, then it is changed and the English version of the field is changed accordingly. If the new Town name isn't listed, then both Welsh and English Town fields are changed to match the new Town name (one has to presume that the English and Welsh name is the same).

That to me looks like both fields needing to be calculations, but how can one calculation reference another and overrule it in certain circumstances?

Unless there is a far easier way of doing it of course : )

[comment]

That's exactly my point: I believe there IS an easier way, and that is for the user to SELECT the town from a 'list of recognised towns', which would be stored in another table. See the attached for an example how this might work.

Dictionary.fp7.zip

[fabriceN]

But be careful with English/Welsh translation :

http://news.bbc.co.uk/2/hi/uk_news/wales/7702913.stm

[Mantic Cow]

That works very nicely with defined lists but as I said, the user needs to be able to enter a value that isn't listed. I could change the drop down to a pop up and include Other for additions but this will only work visually with short lists.

Still, I think that you're onto something there - I'll play around with it and check the list lengths.

Thanks for your help (and patience).

LOL on the sign : )

[comment]

You could use a lookup instead of just displaying the related value. Or an "override" field. That would enable users to enter their own values. I'd be careful with that, though, because it also opens the door to misspelled entries of values that ARE on the list, and other kinds of mess.

[El_Pablo]

Sorry to post in an old thread, but I have the same difficulty here. In my case, it's french and english.

What would be the best way to create a text calculated field when there's more than one language?

Calculation example

if (lang = "en";

   if (x; "yes"; "no");

if (lang = "fr";

   if (x; "oui"; "non")

))

This method cause a maintenance problem if we need to add more fields or worse a new language.

What would you suggest to make the application language independent?

[El_Pablo]

Here I made an example. The problem with this method is that each time I create a new calculated field which returns a text in the "data" table. I need to create the necessary fields in the "dictionary" table.

language.zip