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

[Tilghman Lesher]

On Monday 24 August 2009 19:40:39 Nicolas Chapleau wrote:
> 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.

They are in code only.  Basically, the idea is that if you have es_ES, es_MX,
or es_CO, or any one of many other regional codes for language "es", they
will all follow the same grammatical rules.  Previously, your language code
had to match EXACTLY.  Now, if you have "es_MX_company1" as your language,
it will follow the grammatical rules for "es", if more specific rules for
"es_MX" or "es_MX_company1" are not found.

> 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.

Yes, but the point is that the bug that required you to have the language
spot-on to get the grammatical rules has been fixed.  You can now create
as many derivatives of "fr" as you like, and they will all use the grammatical
rules for "fr".

> 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.

The point is that you shouldn't need to.  You can create derivatives of the
language that contains ALL of your prompts, including any dates, numbers, or
others that you want pronounced differently, and they will all follow the
language.  When a prompt isn't found in your special collection, the language
setting will be used to find more generic prompts to substitute.  It's a
pretty good schema meant to ensure that fallbacks exist, so you won't need to
create entire voice libraries, merely to substitute one or two prompts.

-- 
Tilghman & Teryl
with Peter, Cottontail, Midnight, Thumper, & Johnny (bunnies)
and Harry, BB, & George (dogs)