I'm using a script to run a Google API, but I want it to happen in a CALC field.

 

To better illustrate, I'm translating text that's in a field from English to Spanish using a Google API. I am using InsertFromURL in a script. Can I instead use a calculation field to do the same thing?

 

Thanks.

Not really - unless you use a plugin where the communication with an API is implemented as a function.

Why would you need this? If you want the translation to happen automatically, you can use a script trigger.

 

You have better error trapping and avoid hitting api thresholds using a scripted operation. 

 

16 hours ago, comment said:

Not really - unless you use a plugin where the communication with an API is implemented as a function.

Why would you need this? If you want the translation to happen automatically, you can use a script trigger.

 

There are a few reasons why I consider a CALC field to be preferable although there might well be several suggest other. For one, if the translated text is used on more than one layout, slide, etc., I'd have to preplan each trigger and consider every way it could go wrong. With a CALC field, wherever I put it, the work is done for me.

4 hours ago, Ocean West said:

You have better error trapping and avoid hitting api thresholds using a scripted operation. 

 

Fair point, but is it even possible without a plugin to use a CALC field?

Here’s a quick and dirty look at what I’m doing. 

I actually just ran into a reason why a script trigger is ineffective for me. In the attached video (above), I'm working with a single record therefore easily accomplished with a script. Now though, I need to present multiple records, each with the same info, through a portal.

14 minutes ago, Jeffrey Bloch said:

There are a few reasons why I consider a CALC field to be preferable although there might well be several suggest other. For one, if the translated text is used on more than one layout, slide, etc., I'd have to preplan each trigger and consider every way it could go wrong. With a CALC field, wherever I put it, the work is done for me.

Fair point, but is it even possible without a plugin to use a CALC field?

Here’s a quick and dirty look at what I’m doing. 

I actually just ran into a reason why a script trigger is ineffective for me. In the attached video (above), I'm working with a single record therefore easily accomplished with a script. Now though, I need to present multiple records, each with the same info, through a portal.

 

1 hour ago, Jeffrey Bloch said:

if the translated text is used on more than one layout, slide, etc., I'd have to preplan each trigger

True - but only if you allow the text to be entered/modified on the other layouts. 

1 hour ago, Jeffrey Bloch said:

I actually just ran into a reason why a script trigger is ineffective for me. ...  I need to present multiple records, each with the same info, through a portal.

A script can loop through the related records and translate each one in turn.

It seems you need the text to be available in several pre-defined languages. Perhaps you should consider performing all the necessary translations once, and then just recalling the desired version. Then you can use a script for the first part, and a calculation field for the second part.

 

Edited October 26, 20223 yr by comment

1 hour ago, comment said:

True - but only if you allow the text to be entered/modified on the other layouts. 

A script can loop through the related records and translate each one in turn.

It seems you need the text to be available in several pre-defined languages. Perhaps you should consider performing all the necessary translations once, and then just recalling the desired version. Then you can use a script for the first part, and a calculation field for the second part.

 

This is a live dispatch system and fields can be modified at any time. I considered spinning through all languages at time of entry but the overhead, and cost, would be substantial and for the most part unnecessary. I'm allowing users to select from 55 languages, all that Google offers. When a user elects a different language, many translations need to occur and be updated as needed.

1 hour ago, Jeffrey Bloch said:

I'm allowing users to select from 55 languages

It's hard to see the entire picture. I suppose that if I had to satisfy such a wide range of users, I would let each user define their preferred language as a setting, not as as a viewing choice that can be changed at whim, on any layout.

 

7 minutes ago, comment said:

It's hard to see the entire picture. I suppose that if I had to satisfy such a wide range of users, I would let each user define their preferred language as a setting, not as as a viewing choice that can be changed at whim, on any layout.

 

Each user does select their own language but with thousands of incidents and multiple fields per incident, every incident they were assigned to would have to be stored somewhere, updated each time any change was made to the incident, and would add another, excruciating layer to the design. There'd have to be scripting as well just for the remote occasion when a user decides to select a different language, something I'm sure will happen more often as prospects try to make the system fail or at least try every bell and whistle.

As I said, I don't see the entire picture. My gut feeling is that translating each piece of text once would be more efficient than translating on-the-fly. Keep in mind that if the translation is not stored somewhere, then it will be performed anew on every window refresh.

In any case, I think we have exhausted the available options. If you really want this to be a calculation field, then I believe a plugin is your only choice.