I am implementing a UCCX that is hosted in Australia but will have agents in timeszones across Asia. I have configured individual holiday script checks for each contact centre but during testing each script is using the default IVR language and timezone settings. The xml lookup is working fine, I just don't know the scripting to specify the language folder and alternative timezones.
The way I have done this in the past is to create a string variable which is set in a Switch String step to a language name - e.g. en_GB - based upon which trigger number was called.
This string variable is then used to construct the directory path to the appropriate language folder. The prompts in the language folders use the same naming convention - e.g. WelcomePrompt.wav - so one script can serve multiple languages.
I use the same methodology to point to XML files containing holiday dates, opening times etc.
For language you can use the Set Contact Info step to change the contact language. This will get it to search the other langauge folder without needing to muck around with appending folder strings to the prompt location.
As for timezone: the steps relevent to time (e.g. Time of Day, Day of Week) have a Timezone parameter now. You can use a variable to tell the step which timezone to operate in.
You already have two good posts, but I'll add my own thoughts, since I too operate in a global environment.
Like Jon said, since UCCX 8.5 we have had Timezone support in the scripts where it's most obvious: Day of Week and Time of Day. However, this does nothing for you if you are using XML files to compute Holidays, which I read in your post that you are doing.
How you accomplish that is with a TimeZone vairable and a Date variable like so (untested code off the top of my head - requires testing):
TimeZone target_timezone = TZ[America/Chicago]
Date today = D[now]
Date holiday = D[now]
boolean is_holiday = False
/* Fix the TimeZone for the today variable so that it adjusts to the target TimeZone. */
/* Note that there is no method to set/update the TimeZone on a Date object, */
/* and an enhancement request has already submitted to Cisco. */
/* For now, this is how you work around that: */
Set today = D[today, target_timezone]
/* Your XML documents steps here, where the result is a new Date object representing the holiday */
xml_holidays = Create XML Document(xml_holidays)
Set i = 1
Lable Get Next Holiday
xpath_result = Get XML Document Data(xml_holidays, "//holiday[" + i + "]")
If (xpath_result != null && xpath_result.trim() != "")
Set holiday = D[xpath_result]
/* You don't need to change the TimeZone of the holiday because when you instantiate your */
/* new holiday Date object from the data in the XML file, you do not specify a Time, only a Date. */
/* Becuase of this, the holiday Date variable Time value will be 12:00am (midnight), and if you adjust */
/* for the target_timezone, and if it's "behind" the primary server time by an hour or more, */
/* then you will affectively decrement the date by one day. E.g, Jan 1, 2013 @ 12:00am becomes Dec 31st, 2012 @ 11:00pm */
/* So, just get to comparing the two date objects, ignoring their Time values */
If (holiday.month == today.month && holiday.date == today.date && holiday.year == today.year)
/* Today is a holiday */
Set is_holiday = true
/* This is not a holiday, try again */
Goto Get Next Holiday
/* There's no more holidays in the file */
I wouldn't use a String variable for the language personally, I would use a Language variable.
Changing the language varies depending on where you want to do it, and if you want it to be temporary or perminent.
If you publish a number in Asia, and you know that the callers are all of the same language, you can just change the language on the Trigger. This will last for the duration of the call on that trigger, provided you don't use the Call Redirect/Call Consult Transfer steps to send the caller somewhere else.
Using this method will automatically change where Prompts and Documents are searched for.
This says, "get the document "my_document.xml" from the language folder which matches the Contact's current language."
So if your Trigger was set to "zh", then the document will be searched for in the "zh" language folder.
You can start all scripts off in English as a default language, but then have a menu that says somehting like: "Para Español, Prensa 7". Under the branch for that Menu option, you would do like Jon said and use the Set Contact Info step to change the language from this point forward to Spanish.
If you wanted to play the above menu option number 7 in Spanish, while the rest of the prompt plays in English, you have two choices:
The second option could look like this (I'll even throw in another languge for fun):
Menu (--Triggering Contact--, P[main_menu_options.wav] + P[main_menu_language.wav] @ L[es_ES] + P[main_menu_language.wav] @ L[zh])
You may not have used the Prompt concatentation operator before, so allow me to clarify the above example. The "+" is used to concatenate multiple prompts together. Think of this like a playlist in your music player. It starts with the prompt on the left, and then goes through the list, to the right, playing each prompt, one right after another.
The actual language change is the "@" qualifier, and then the language literal after it.
P[my_prompt.wav] @ L[en_US]
This says: "play the prompt "my_prompt.wav" from the "en_US" language folder."
Changing a Document's language is exactly like changing a Prompt's language.
DOC[my_document.xml] @ L[zh]
This says, "get the document "my_document.xml" from the "zh" language folder."
Good luck to you!
Please use the star ratings to help drive great content to the top of searches.