You can't really script changing the actual field name, so instead you'd create a field to serve as each label.
Although it could be scripted ("OnlayoutEnter" set field WineLabel to..." your script would need to change every label on every layout) so...
I think calculation fields would be a simpler bet.
If it were me, I'd add these fields to a single record Table (your db may already have one). which related to all (using the "X" option in Relationship dbox)
Following is one possible way on how to go about it.
1. In the "Labels" Table create a text field with a preference for language choice named 'language'
2. For each "label" I'd create a calculation field which changed according to the language choice.'
Examples: Calculation for a field name WineLabel
If (language = "French", "Vin: ; "Wine")
or for multiple options:
Case ( language = "French" ; "Vin" ;
language = "Italian" ; "Vino" ;
Fagreement: I didn't mention following cuz too obvious, but...
If you want to keep your DB lean and mean AND you only have 2 languages and a few layouts.
The downside of this technique is database maintanence, If you're like me, constantaly tweaking layouts, you'll have a tricky job maintaining the DB. But if you're the sort that's done when done -- it's an effective alternative.
When done with your layout designs: Duplicate all layouts in language 1, manually change field labels.
Then: 1) Add a simple language choice field (as above), 2) In all your "go to layout" type scripts decide where to go based on language choice. (kindof same as when people multipurpose for screen size or platform) the difference is that either your user would need to intervene in selecting a language (at least on first launch), or you'd need to script it based on user.
Another option would be to use conditional formatting on the field labels. Have both languages but set one to the background color when you want the other displayed.
For your need, Fagreement, I would consider merge variables. Keep in mind that merge variables and calculations alike will completely disappear in Find mode so you may have to include globals to provide your labels dynamically when in Find. If you use merge variables then you can hold all your calculations within one simple object on a layout (for labels being displayed on that layout). A single merge variable can change its text as needed; no need to stack objects conditionally colorized. Put together merge variables, conditional formatting and the wonderful Let() function and magic happens ...
Attached are examples. Note that the 'I declare variables' is underneath a field to force refresh. This 'I declare variables' must be lower in stacking order than any of the objects it evaluates (select it and send to the back using Arrange). I place it at top of all layouts in same place. You can put many things within the 'I declare variables' Let() statement. Sometimes I add another one to specifically force a field to refresh, such as these examples. This eliminates the need for script triggers attached at layout level to force refresh.
"I declare' does not show because conditonal formatting only allows it to show in layout mode (4) so the Developer knows where it is at. BTW, I use this also to place developer notes on layouts that won't be seen unless in layout mode. It helps me identify hidden portals or stacked objects if I 'point' to them with notes. I handle many of my maintence items for a layout within 'I declare', such as tracking the IDs automatically, naming my layouts by calculation, I even attach "object" to it as an object name and use it to remove cursors from fields without commiting the record (Go To Object 'Object').
I first saw it used by Comment, one of the very top Developers in this business. I would not live without it now and it is standard on every user layout I create. It saves from creating needless calculations and it does a whole lot more. I pre-load it with all my standards as I build a solution.
LayoutVariable: Wants list report and if their policy is CAR, show car make & model. If policy is HOUSE, show house address.
VarDisplay: Shows ... $price (Royalty * price)
I'm trying to use the onditional formatting on the field labels, but when I put the labels one above the othe,
on browse mode I have the label not clear, if I put the label behind the other (sedn to back on layout mode) then on browse mode I have it clear.
I tried to play with the color background but it's the same issue.
A better way to make layout text invisibile is to use conditional formatting to set the font size at 500. That method will allow you to "stack" text on top of each other with only one object in the stack visible at one time.
That said, I recommend taking another look at one of the field based solutions already suggested here. I think they will be a better approach for this type of situation and text in a table can be much easier to edit and maintain than blocks of layout text layered on top of each other. Think of the changes you'd need to make to your layouts if you added a third language to your layouts. With the field label text in a table, adding more languages could be as simple as editing the data once in this table aby adding one or more records.
thanks it works