Question on Numbers and “localized string”

Scripting Forums AppleScript | Mac OS X
#1

I just hit upon an AppleScript behavior that would be extremely nice for "do shell script"ers, outside the English speaking world if reliable:

123.456 as string
will use the system settings for number formats (as with any real). For most European settings, this means, the dot becomes a comma. Nasty for shell scripts. It is even worse for people using Arabic formats: Even the digits are changed - Arabic numerals in the narrow sense of the word.

By accident I found that “localized string of” behaves differently. To make very clear what I am talking about, I switched my format settings to Egypt. The following lines show some number to string conversions and the result in AppleScript:


localized string 1.23123456789023E+14
	--> "123123456789023"
1.23123456789023E+14 as string
	--> "١٫٢٣١٢٣٤٥٦٧٨٩اس+١٤"
localized string 1.23123456789023E+12
	--> "1231234567890.23"
1.23123456789023E+12 as string
	--> "١٫٢٣١٢٣٤٥٦٧٨٩اس+١٢"
localized string 1.23123456789023E+140
	--> " 1.23123456789023e+140"
1.23123456789023E+140 as string
	--> "١٫٢٣١٢٣٤٥٦٧٨٩اس+١٤٠"

(I tried this under OS X 10.6.6 and 10.5.8. The behavior was consistent.)

If this is reliable, it is a nice feature for international use of “do shell script” e.g. in communication with an SQL database server.

So my question is: Does anybody have some information, if this is the side effect of some strange implementation or is it a feature that can be used?

Regards, Jürgen

#2

This looks interesting. But both the AppleScript Language Guide and the StandardAdditions dictionary specify a text parameter for ‘localized string’, not an AppleScript number. I wouldn’t rely on its behaviour with numbers ” at least for the moment.

The behaviour appears similar to that of unit coecions, which have been used as a hack for some time:

1.23123456789023E+14 as kilometers as text
--> "123123456789023"

I notice that some real values which had precision problems in earlier versions of AppleScript work OK in AS 2.1.2. For instance, if I compile the number 8483.36 on my Tiger machine, what appears on the screen is 8483.360000000001. Similarly when the number is coerced to text. On my Snow Leopard machine, it appears correctly as 8483.36. However, applying ‘localized string’ or a unit coercion to it reintroduces the old precision error:

localized string 8483.36 --> "8483.360000000001"

8483.36 as degrees Celsius as text --> "8483.360000000001"
#3

Good point, thank’s for the note. (It would have been sooo nice!)

I was not aware of that old unit coercion trick.

Did precision get better or got hiding the problem better?


(0.7 + 0.1) < 0.8
--> true

Is there any solution to that? Every language I know behaves that way: Some simple decimal numbers are just repeating in dual notation.

Thank’s again, Jürgen

#4

localized string is not designed to change the format of numbers.

It’s a function of Standard Additions.

localized string‚v : Return the localized string for the specified key
localized string text : the key
[from table text] : the name of the strings file excluding the “.strings” suffix (default is “Localizable”)
[in bundle file] : an alias or file reference to the bundle containing the strings file (default is the current application/script bundle)
→ text : the localized string

Example :


tell application "Safari"
	
	get localized string "Are you sure you want to close this window?"
	
end tell

Since 10.6, there is an annoying feature.
Calling an OSAX from a tell application “wxyz” block generates errors
Happily they are automatically trapped.

On a French system,running the script above issue this log report


tell application "Safari"
	localized string "Are you sure you want to close this window?"
		--> error number -1708
	«event ascrgdut»
		--> error number -1708
	localized string "Are you sure you want to close this window?"
		--> "Souhaitez-vous vraiment fermer cette fenêtre ?"
end tell
Résultat :
"Souhaitez-vous vraiment fermer cette fenêtre ?"

Yvan KOENIG (VALLAURIS, France) vendredi 21 janvier 2011 18:19:54