I doubt that placeholders in localized strings work in AppleScript.

In Cocoa placeholders are used in conjunction with the method stringWithFormat: of NSString,
which replaces the placeholder tokens (%@, %d, %f etc.) with the appropriate parameter values.

There is no equivalent in AppleScript, even in AppleScriptObjC stringWithFormat_() doesn't work with non-object parameters

You may create a resource containing :
begOfString1
endOfString1
begOfString2
endOfString2
begOfString3
endOfString3

In the script you may re-create the complete string with :
set theCompleteString to localized_begOfString1 & variableItem & localized_endOfString1

I do that in scripts building formulas for Numbers spreadsheets.

Yvan KOENIG (VALLAURIS, France) mercredi 28 mars 2012 15:52:55

Placeholders can not be used, like Stefan said, but still, I think that concept is the best way. Write some simple text search and replace handler (there are probably 1000 suggestions for such handlers on this site). Variables in strings could be expressed like <<temperature>> or something similar. Thinking about text fragments for all possible grammar rules will drive you crazy.

First, you take the localized string, second, you replace the variable string.



Jürgen

Elegache,

printf is also an terminal command so I use it myself like when a user is asked to confirm a text like 'Are you sure you want to delete the 5 selected items?' where the number 5 is variable.

"teststring" = "A string with an integer %d and another %s";

Then in applescript I use a small handler to get the localized strings. Give up an empty array or use just the localized string command when there are no variables in the string.

Applescript:

localizedString("teststring", {10, "string value"})

on localizedString(stringKey, stringValues)
   set command to "printf " & quoted form of (localized string stringKey)
   repeat with p in stringValues
       set command to command & space & quoted form of (contents of p as string)
   end repeat
   return do shell script command
end localizedString

EDIT:
The reason I use it with these placeholders is that localized string files can be easily used with Objective-C as well. You should keep that in mind if you want to translate the project slowly to Objective-C in the future and maybe Objective-C and AppleScript need the same string from the localized file.

Last edited by DJ Bazzie Wazzie (2012-03-29 04:54:16 am)

Dear MacScripters,

As you all will soon discover - I'm a little slow then it comes to reading the documentation . . .

So imagine my surprise when I investigated the change verb that is supplied by the Satimage.osax . . . .

Just a little further down is:printf!

Works just as advertised and should be lightening fast compared using the UNIX command printf.

Is there some reason why folks don't avail themselves of these extensions?  I realize that commercial developers can't easily ask their clients to install this.  However I'm giving away my "toys" for free.  Is there some other reason why AppleScript developers shy away from using these extensions that - I should be worrying about!

Thanks for all the help!!

Cheers, Edouard

Dear MacScripters,

Okay, so call me greedy, but I decided to try to write a single AppleScript handler that would be able to localize strings, then run printf.  If the Satimage osax was installed, it would use that printf extension, otherwise it would create a UNIX command and do that.  So I naively used a try-block and used the UNIX as the fall-back.  However, I realized that this couldn't possibly work.  If the Satimage osax wasn't installed - then there would be a compile-time, not run-time error.

*Gulp*, that's the trouble.   Because, even with this obvious impossibility - it works!?!?  Here is my code as it appears on my Mac which has Satimage osax installed:

Applescript:

set convertedString to "Outside temperature has exceeded the threshold of: %d˚ at %s."
set variableList to {50, "2:19pm"}

localizeVarStrings(convertedString, variableList)

on localizeVarStrings(localString, variableList)
   -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   -- Routine to localize a string that includes printf formatting codes and then
   -- substitute the values for the format codes.
   -- uses Satimage osax when installed and UNIX printf command
   -- as fall-back
   --
   -- Thanks to Adam Bell for nifty list to string concatenation.
   -- http://macscripter.net/viewtopic.php?pid=53342#p53342
   -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   local convertedString, variableString, tdl, quotedVariableList, variableValueStr
   
   -- First get translated string from localizable.strings file
   set convertedString to (localized string localString)
   
   try
       -- try Satimage printf extension
       set convertedString to printf convertedString parameters variableList
   on error
       -- Convert values for printf into shell-friendly form.
       set quotedVariableList to {}
       repeat with variableValue in variableList
           set variableValueStr to contents of variableValue as string
           set end of quotedVariableList to quoted form of variableValueStr
       end repeat
       
       -- Now make printf values into a single string
       set {tdl, text item delimiters} to {text item delimiters, space}
       set variableString to quotedVariableList as string
       set text item delimiters to tdl
       set convertedString to quoted form of convertedString
       -- Finally let UNIX do the printf work.
       set convertedString to do shell script ("printf " & convertedString & space & variableString)
   end try
   
   return (convertedString)
end localizeVarStrings

If I copy this script to a Mac that doesn't have Satimage osax installed, the line:

set convertedString to printf convertedString parameters variableList

looks instead like this:

set convertedString to «event SATIprtf» convertedString «class para» variableList

However, that doesn't generate a compile-time error.  Now I recognize that these are raw Apple events and my understanding is that this should be reasonable.  The «event SATIprtf» is unavailable on Macs without the Satimage osax installed, so the handler goes on to do the error code which uses the  UNIX printf just as I want to.

However, . . . . this sure look a little weird to me.  Am I doing something crazy here that only a AppleScript guru would properly understand?  Can code like this be distributed without risking problems for "innocent users"?

Curious minds want to know!!

Cheers, Edouard

P.S. Here is a link to printf localized string test.scptd file complete with the localized string resources for folks to play with.  According to the tests I've run, this file should work on any Mac, even if just cutting and pasting the code above will not work unless you have the Satimage osax installed.

Dear Shane and MacScripters,

Oops, you are correct:

Shane Stanley wrote:

set convertedString to «event SATIprtf» convertedString «class para» variableList

That doesn't look right -- I'd expect something more like:

Applescript:

set convertedString to «event SATIprtf» convertedString given «class para»:variableList

I typed in that line "by hand" since it was coming from another Mac and in my haste I forgot the given.

However, you left my key question unanswered.  Can such code be used "safely" in general?  It is certainly very kludgy, but AppleScript is hardly the elegant scripting language that I suppose the originators at Apple first intended.  At some point you've gotta compromise and make your scripts usable to the folks who want to use them!!

Cheers, Edouard

elagache wrote:

However, you left my key question unanswered.  Can such code be used "safely" in general?

I don't see why not -- it compiles fine, and you trap the error. I can see where Stefan is coming from -- although I'm amazed at how AppleScript beggars are often such choosers -- but it seems to me that doing it as you propose covers that objection.

And unless I'm misunderstanding, your script by definition is designed to be used in app packages, so the option of adding a scripting addition is, at least technically, simple in this case.