Calculate a calculation??? (or using placeholders)

[wookie]

I'm trying to optimize my localization procedures. The language strings are stored in one spot as repeat fields but are used over multiple files, which makes it easy for me to keep the overview and to switch the language. The disadvantage however is, that when the language is changed, I need to copy each individual repetition from the specific language repeat field into its respective new language repeat field. This works, but however is abit annoying as the script to do this gets pretty long (countless language strings * number of languages). nuff said.

My question: Is it possible to do a calculation with the use of placeholders?

Imagine the following fields:

[color:"purple"]

Language_GER (Text, Repeat)

Language_ENG (Text, Repeat)

New_Language (Global, Text)

Using a script "New_Language" will be set to either "Language_GER" or "Language_ENG".

Now: To retrieve for exmaple to value of the 2nd repetition regarding to the chosen language, I'd love to do calculation like this

[color:"purple"]GetRepetition(New_Language;2)

But as "New_Language" is not a repetition (if it would be, the script would have to take care of each individual repetition, which brings me right back to where I am) this doesn't work.

I want the calculation above to understand that "New_Language" should be replaced with the name of the field (either Language_GER or ..._ENG), not its content. So basically [color:"purple"]"GetRepeation(" & New_Language & ";2)" [color:"black"](this doesn't work either as FMP handles this as text not as function) [color:"purple"]

-> GetRepeation(Language_GER;2) [color:"black"]if "New_Language" has been set to "Language_GER".

Do you get the point?

[Ugo DI LUCA]

Wouldn't know how far this could lead you, but a global field can be "formated" as a repetition.

That's quite the only use I have of GetRepetition....

[wookie]

"...but a global field can be "formated" as a repetition"

I know. But that's not the point, as you can't copy one repeating field to another repeating field including all repetitions with just a single command. Rather this requires one script step for each repetition...

[Ugo DI LUCA]

Hi,

I'm confused and don't really get what you're looking for, but I will go for another try.

Do you happen to have a version with the Get Field Calc.

I couldn't test it as I didn't really understood all the poits here, but if you want a field to hold the value from another field, I'm quite sure Get Field could do it.

If not, pardon me.

[wookie]

GetField... Interesting point, sounds logical.

According to what the reference manual says about GetField, the calc then looks like this[color:"purple"]

GetRepetition(GetField ("New_Language"); 2)

Unfortunately GetRepetion doesn't seem to allow nesting, as the above calc results in this error:

[Ugo DI LUCA]

Hi,

It seems I need some sleep, cause I would have made the calc GetField(GetRepetition... instead.

[wookie]

Vaughan, semi god of FMP, no ideas ?-)

[danjacoby]

How about:

If(New_Language = "German")

GetRepetition (Language_GER, 2)

End If

If(New_Language = "English")

GetRepetition (Language_ENG, 2)

End If

That way, if they haven't put in a language, they get nothing.

[djgogi]

But that's not the point, as you can't copy one repeating field to another repeating field including all repetitions with just a single command. Rather this requires one script step for each repetition...

Take a look on Math with Text to see how to perform it even without any scripting.

For ex.

having gReps text repated emtpy field with 1000 (max num of reps), you could define your gLanguage field as an calculated repated field im this manner:

cLanguage=gReps & case(currentLanguage="Ger", Language_ger, currentLanguage="Eng", Language_ger, Language_default)

Dj

[wookie]

To help you understand my question, I took two of my actual files and simplified them by removing everything but the parts which are required to demonstrate what the current problem is. (Well it's not really a problem, but I'd like to further optimize it so that the scripts can be even shorter). You'll find those examples attached! (The plug-in is Mac only and just required to show a language specific dialog).

I'd recommend that follow the on-screen instructions to do a test run first, then use the ScriptManager to analyse the scripts. I made some comments within the scripts.

[color:"brown"] Please keep my intial post in mind!

[wookie]

If(New_Language = "German")

GetRepetition (Language_GER, 2)

End If

If(New_Language = "English")

GetRepetition (Language_ENG, 2)

End If

This is the obvious way to handle it. However the hUUUUge disadvantage is, that wherever a text string is required the calculation first needs the checks against the chosen language. If you have, let's say 8 languages to choose from and you're dealing with 200 or 300 text strings, it terribly bloats the whole app!

Take a look at my example files: Using a script, the language is only tested once (! - that is to say only after the language has been changed). In this script each string of the chosen language are 'copied' to a generic (repeat) field. Doing this, I just have to call the generic field, regardless of which language has been chosen.

But as my initial post states, I'm looking for a way to shorten this script...

[Ugo DI LUCA]

Hi,

This will not answer your question, but as you provided a clear example, I'll jump on it.

Even if we now know how interresting and useful repeating fields may be, could you just tell me why you prefered having repeating fields rather than relationships.

I'm now very curious to know from developpers on board what could be the pros and cons of such a design.

I'll personnaly go to a relationship and a script that call for a number 1,2,3,4 or 5, these numbers being key fields for a relationship to English, Italian, Dutch, German and whatever.

In addition, as I also thought of a bi-language solution, how can we make the tabs appear while in find mode ?

Finally, from what I see, your solution is working perfectly with one record. Are you meaning it's kind of slow with multiple ones ?

(Updated after a private message with Wookie, in case it could get confusing for other readers. :

Wookie : Which one record are you talking about ?

>Me : Well, I may have messed a little. I was talking about the 2 rules records, but I imagine, your languages settings are dispatched to all the current files. Right ?

Wookie : The Start here.fp5 will be the 'Prefs file' in my later app, which is why it only needs a single record.

Apologizes... )

[Pupiweb]

I did some multi-language stuff some time ago

The system I used - after the suggestions of Serge Schongut, a developer working in Belgium where they have frequently these type of issues - was to use a Lables.fp5 file, one record per language, one *field* per label. On opening the user would choose a language and store it in a global field somewhere, to be used for a relationship to Labels.fp5

Dialogs were handled similarly, using the Troi Dialog plugin to set dynamically the dialog content

Value lists were very tricky and they also were handled similarly, using a numeric parameter for each value list item and looking up values in the chosen language ...

[wookie]

The system I used ... was to use a Lables.fp5 file, one record per language, one *field* per label. On opening the user would choose a language and store it in a global field somewhere, to be used for a relationship to Labels.fp5

That's a(nother) cool way to do this! Still I think my solution as shown in the example file isn't bad either. What I like about my way, when compared to the above mentioned method is, that I don't need an extra file (OK, who cares...), but that I see all strings of all languages on one page (which makes translation comfortable) - however in your solution the last point could be achieved using portal and self-join as well...

Regarding the value lists: I think the effort to tame those is the some, whether I use my current solution or do it the extra Lables.fp5 way.

The central question of this thread still is, if there's a way to 'use a placeholder' in a calc, so to say that FM knows that in [color:"purple"]GetRepetition(New_Language; 2), 'New_Language' actually means ?Language_GER? (if German was selected).

[wookie]

dilucaugo68 came up with an interesting idea:

[color:"#666666"]Ultimately, have you tried a case calculation (set repeating) using a global field (I didn't tried it).

c_choose languages = Case (global = "English"; English; global = "German"; German)

Then use a GetRepetition (c_choose languages; 2)...

I tried to do something like this earlier, but this unfortunately just DOES NOT work. I made an example file which just demonstrates how it fails. See attachment.

Actually this is exactly the problem, why I made my intial posting. GetRepetition/RepeatFields in general don't like placeholders (or at least not such calculated in a certain way)...

[Ugo DI LUCA]

Hi Wookie,

c_choose key = Case (selection= "A"; FieldA; selection = "B"; Field

Then use a GetRepetition (c_choose key; 2)...

doesn't work

But what WORKS is :

c_choose field = Case(Selection = "A", GetRepetition (FiedA, 3), GetRepetition (FieldB, 3)).

...that is converting Crazy Dan 's script "If..." into a Case calc valid for each field at the fly.

You could even use :

a "globalnum" field to select the repeat number

c_complicated = Case(Selection = "A", GetRepetition (FiedA, globalnum), GetRepetition (FieldB, globalnum).

...Now, going backwards on this thread...

"...but a global field can be "formated" as a repetition"

I know. But that's not the point, as you can't copy one repeating field to another repeating field including all repetitions with just a single command. Rather this requires one script step for each repetition...

Sorry DJ I haven't look to your sample yet, but a lookup can transfer the values from a global repeating field to another field. Have a look to the "AutRep" J.M. Osborne sample at www.fmfiles.com or www.databasepros.com

But you would have the same problem if you use a case calc to decide which key the lookup should use...

More then that, I have no other clue for you...

[Ugo DI LUCA]

Hi,

And finally the sun rises....

Here's a sample with GetRepetition(finalfield,2) using lookups.

Another test on rep.zip

[Pupiweb]

What you see is expected behaviour

I seem to remember there might be a workaround, and some "repeating fields gurus" might remember about it ... I'm too used to use a related file to remember about

What I DO know is that you can make it work using a lookup instead of a calc field (see attached file)

So in your example you'd have a file with a record for each language and a repeating field holding a repetition for each label; in your data file you'd lookup the proper language-related values in a repeating field using a relationship based on the chosen language

Repetition_hates_Calcs.fp5.zip

[Ugo DI LUCA]

Ciao Giuseppe,

Why have wait 2 minutes before posting this one. That"s insane. I feel....

That's why I love you guys developper. Some time late on appointments, but with such a simpler "mind".

Would it work with more than 2 repeating sets ?

Have a good week-end.

Well, I had bet with Wookie he would have solved it before the end of the week-end. Job done. Now it's just a question of ....repetitions or relationships

[wookie]

I finally made the switch from repetitions to relations.

I was afraid of losing some comfort, but the opposite is true. I was able to get rid of a lot of script steps, to simplify/shorten calculations and on top of that, gain a little speed.

Thanks to everyone for his/hers contributions. This is a great forum!