[asterisk-dev] [feature] Support for relative paths for all "say" functions

[Nicolas Chapleau]

I tried to respond to all replies in one response, forgive the delay.

 

1) Nicolas Chapleau wrote:
> 
> > This would also render "say" functions
> > to not play the correct language syntax for numbers, dates and times as
> > the functions are not aware on how to play fr_special1, fr_special2, ...
> 
> I believe you might be right, in which case this is a bug that must be
> fixed. All parts of Asterisk that interpret LANGUAGE should handle it
> the same way.

 

tilghman reports that this issue has been fixed:

 

> Actually, that it worked only for a particular 2-digit language code was a bug
> and has since been corrected. So creating a specific derivative of a language
> should not be a problem.

 

Are the derivatives created in code or in a .conf file of some sort. I've been looking at the docs to no avail, other then in code.

2) Andreas Sikkema wrote:
 
> What I think he means is something slightly different.
> 
> That you can have multiple voices within one language so that there 
> will be no problems wrt digit pronunciation because that already 
> "works" for the language.
> 
> Currently all the special stuff for pronunciation is related to the 
> two digit country code. If you need more than two voices for a 
> specific language (multi tenant asterisk install or something like 
> that) you need to create a special language (in his example fr and 
> fr_special) but then I think you'd lose the pronunciation rules 
> because that only works for the two digit country code and not for 
> something else.
> 


Andreas is pretty much bang on as to what we are trying to achieve and I believe many others are probably having this issue. I'm still trying to come up with a "fix" or "solution" for digits/letters and phonetics to behave the same way as normal play functions and I will report later.

 

 

3) Kevin P. Fleming wrote:


> My point was that Asterisk is already prepared (when finding prompts) to
> automatically 'shorten' the LANGUAGE code by removing suffixes until it
> finds what it is looking for; so if you have set LANGUAGE to fr_special,
> and you ask for 'demo-instruct' to be played, Asterisk will first look
> for demo-instruct in the fr_special directory, then in the fr directory,
> and finally in the 'no language code' directory.
> 
> I am suggesting that the code in Asterisk that directly responds to
> language codes (say.c, app_voicemail.c and other places) should *ALSO*
> automatically shorten language codes, so that if LANGUAGE is set to
> fr_special then say.c will still use the fr syntax for speaking
> numbers/dates/times.
> 

 

They already do. However I believe that there should be a better way to set this up other then creating special language flags for different voices in the same language ONLY for the SAY functions. 

All works fine and dandy for normal playback functions.

 

English:

sounds/voice1

sounds/voice2

sounds/digits

sounds/voice1/digits

sounds/voice2/digits

 

French - or add your language here ;)

sounds/fr/voice1

sounds/fr/voice2

sounds/fr/digits

sounds/fr/voice1/digits

sounds/fr/voice2/digits

 

ie: language set to fr => playback(welcome), playback(voice1/welcome), playback(voice2/welcome), ...

 

but not for "say" functions and such:

 

ie: sayNumber(1234) -> OK, sayNumber(voice1/1234) -> wrong, sayNumber(voice2/1234) -> wrong

 

and this is what I'm trying to achieve. It would be nice for both to behave the same. I also do not wish to change any syntax for these commands. I have an idea, so I will test it out and report back shortly.

 

Thanks all for your valued input and I hope I'm not wasting anyone's time.

 

NicChap.

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090825/b370faf6/attachment.htm