Localised weekday?

Just out of curiosity: are localised weekday names available somewhere in the system?
I was modifying a datestamping routine to include those, when that came up as a possible way of getting them.
What I did use was simple enough:

-- full day name
set localisedWeekDay to word 1 of ((current date) as text)
-- or abbreviated
set localisedWeekDay to (text items 1 thru 2 of ((current date) as text)) as text
-- memo to self: must respect TIDs here, or face tuttuttutting from peers

Another way would be a lookup table with day numbers and names (which that system file is, conceptually).

It is defined in the the nl_NL.utf-8 directory in /usr/share/locale. The file LC_TIME is the file with the weekday names in it. I’m assuming that your system locale is set to Dutch.

Bad news if you expected it to be a bit general:

current date
-->	date "14 de Agosto de 2012 12:17:11"

date string of (current date)

--> "terça-feira, 14 de agosto de 2012"


Something like this?

Correct modified code below. Aware that link opens in new window/tab, you can scroll to post #12.

Oh dear… No, I wasn’t aiming for locale-agnostic code. Thanks for reminding me…
[Might have found out anyway - I’m signed up for a course in Portuguese, starting in a few weeks. I’m confident I’ll know how to say ‘next tuesday’ pretty soon :wink: ]

Mmyes. Not exactly a lookup table. Just a list of strings; I don’t think I would want to rely on their order.

I think your handler should be used like so:

timeLocalStrings((weekday of (current date) as text), "en_US", "nl_NL")

In a way, this uses the two LC_TIME files as one lookup table.
It should work with abbreviated names too, presumably. I don’t think you can get those with AppleScript, so for that you’d need a lookup table in the script.
Maybe hard-code the en_US file, and loose the 2nd parameter, to avoid mistakes.
Thank you, gentlemen.

You’re correct that you can’t depend on the order without a base. Every file has the same order so when you lookup the line in one file you can print the line in another file. LC_TIME files work this way because they are faster and saves space compared to localization strings, but the principle remains the same.


I’m using 10.8.
When I run the posted script with the calling instruction :

timeLocalStrings((weekday of (current date) as text), “en_US”, “nl_NL”)

I get :

do shell script “cat ‘/usr/share/locale/en_US.UTF-8/LC_TIME’ | sed -n ‘/Tuesday/ =’”
→ “34”
Résultat :
error “Il est impossible de régler ln of 34 à "/usr/share/locale/nl_NL.UTF-8/LC_TIME".” number -10006 from «class LN » of 34

Am I making something wrongly ?

Yvan KOENIG (VALLAURIS, France) mardi 14 août 2012 19:15:33

Yvan, no. It seems we are both using an osax DJ does not have. Change his ln variable, and she’ll work. Satimage?

DJ, just for fun I tried the script with an abbreviated day name. And learned something about sed - I think.
With an abbreviated name you get 2 line numbers, so it seems to apply a ‘contains’ condition, not “is equal to”.
I just looked at the sed manpage for the 1st time ever, which didn’t me much good.


You are right. Satimage is installed on my machine.
I use it from time to time to test script which I am asked to debug.

I’m wondering why I missed that because, the script editor display ln as other functions, not as a variable name.

Yvan KOENIG (VALLAURIS, France) mardi 14 août 2012 20:43:05

Is there any other way to get the current locale (vanilla AS) , than using the code below?

And this isn’t safe on Tiger at least, as I think I remember?

set theLocale to (do shell script " echo $LC_ALL" )

In this case when an abbrev is sought for you can surround it by ^ and $, then you won’t get more, as sed is greedy.

Regulus and McUsr are both right. Some entries are multiple times in the same file. So we need to tell sed also to quit on first result. Also it should work with satimage users which, correctly mentioned, I don’t have installed.

timeLocalStrings("ma", "nl_NL", "en_US")

on timeLocalStrings(str, _from, _to)
	set validLocales to every paragraph of (do shell script "ls /usr/share/locale | grep -i '.utf-8$' | awk -F. '{print $1}'")
	if _from is not in validLocales or _to is not in validLocales then return str
	set fPath to "/usr/share/locale/" & _from & ".UTF-8/LC_TIME"
	set tPath to "/usr/share/locale/" & _to & ".UTF-8/LC_TIME"
	set lineNumber to (do shell script "cat " & quoted form of fPath & " | sed -n '/^" & str & "$/ {=;q;}'") as integer
	if lineNumber = 0 then return str
	return do shell script "cat " & quoted form of tPath & " | sed -n -e '" & lineNumber & "," & lineNumber & "p'"
end timeLocalStrings


Not that it matters much, but awk is notoriously slow, and you are really shooting a sparrow with a cannon when return a field like that with awk. I first tried sed, and that was as hard it seemed, as to change newlines! :slight_smile: Then I remembered cut!

I am really fond of awk too. And there is nothing wrong with your code, just an alternate, and possibley much faster way to get that field returned. :slight_smile: I think it is generally a better way way to return just the first field of a list of a record separated by some delimiter, (period in this case), when no processing of data is needed!

cut -f 1 -d \.

No 100% vanilla, unless you want to write a plist parser in plain A/S.
It’s defaults or System Events otherwise.
I can’t find that file on my 10.6.8 system. It’s a system file anyway (right?), to get the current user’s language/locale you’d read one of his plists:

do shell script "defaults read -g AppleLanguages"
-- or
do shell script "defaults read -g AppleLocale"

Yes, System Events is really as vanilla as AsObjC Runner, but you’d expect it to be there! :slight_smile:

From my first run of the script I guessed that sed does a “contains” match, not “equal to”. In that case, quitting at the 1st match for “Tue” would return “Tuesday” when the order in the LC_TIME is reversed (short names after long names).
So, how does sed match? “equal to” or “contains”?
I can’t find that out from its manpage. It may be there, but hidden by the terminology.

Slow? LOL

AWK is written to outperform the shell big time and succeeded. Weird is that I would suspect that cut is indeed faster but seems not to be true on every machine. On my machine there is no difference, some machines cut is faster and others awk is faster. AWK is pretty awesome and insanely fast for an interpreter.

These are my results:

It is now an exact match.

for instance when you lookup ‘Tue’ you would normally have an contain match. But when you wrap and ^…$ around it (begins with and ends with) it is an exact match.

Good! Dank je.


Here is a version using ASObjC Runner.

--weekday of (current date) as text
timeLocalStrings(result, "en_US", "fr_FR")

on timeLocalStrings(str, _from, _to)
	set vName to path to startup disk as text
	set fPath to vName & "usr:share:locale:" & _from & ".UTF-8:LC_TIME"
	set tPath to vName & ":usr:share:locale:" & _to & ".UTF-8:LC_TIME"
	tell application "System Events"
		{exists disk item fPath, exists disk item tPath}
	end tell
	if result contains false then return str
	paragraphs of (read file fPath)
	tell application "ASObjC Runner"
		set maybe to look in list result matching str
	end tell
	if maybe = {} then return str
	item 1 of maybe
	paragraph result of (read file tPath)
	return result
end timeLocalStrings

Yvan KOENIG (VALLAURIS, France) mercredi 15 août 2012 18:10:15