[asterisk-dev] SaySentence/SoundPack Proposal

Sat Nov 30 21:57:08 CST 2013

On Sat, Nov 30, 2013 at 5:52 AM, Andreas Sikkema <h323 at ramdyne.nl> wrote:

> On 29/11/13 06:03 , Steve Murphy wrote:
>
> > Tzafrir, as far as I know, the locale files are THE place to put such
> > locale specific information.
> > This is no departure from the system of organization presented by GNU
> > gettext, and is in use for
> > hundreds of languages in even more locales. The language pack is exactly
> > tailored for a specific locale.
>
> Locale and language should not be mixed. In the Netherlands it's quite
> common to have both English (en_EN) and Dutch (nl_NL) languages
> available in IVR's, but we wouldn't dare (be allowed) to announce
> pricing in pounds.
>

So, you'd have to put the different money routines
in en_NL, and nl_NL, I might imagine.

>
> In the US Spanish (which one) and English (en_US) are quite common, but
> you wouldn't announce pricing in dollars and pesetas, they should both
> be dollars.
>

Same here, make sure to put the money routines in es_US,
and en_US.

>
> There's load of examples where locale and language are not hard linked,
> so linking them in a language pack is IMHO a bad idea. The problem is of
> course that this, thinking it through, would require every language to
> be able to handle *all* supported locales. There is room for
> optimisation, but there might always be a few people complaining about
> missing Japanese support for the Zimbabwe locale...
>
>
I think, if we understand each other correctly, I have to
agree with you. A proper language pack will include locale
specific utterances under a lang_locale sort of set of files, at least
if it's any good. Don't make the mistake that just because my infant
code doesn't have an en_US or en_GB with the right localizations in it,
that I don't intend to provide them! 

But even if I were foolish enough to
insist on NOT providing them, and supplying only a dollar specific
money sayscript at the language level, you can always override it in
a lang_locale file, and make sure the LANGUAGE gets set up for users
as "lang_locale", instead of just "lang".

As it stands, a language pack could have any number of
locale related files in it, hopefully related to a single
language (to more easily organize things).

The issues that separate the locales could be currency, different
pronunciation (like accents), vocabulary, who knows. It's up to the
sound pack provider to provide as many locales as they want/need. If
that's not good enough, anyone is always welcome to put together the
missing locales for a language. If no one is willing to do the work,
then you get what you get.

BTW, the algorithm to find SayScripts (or translations) is about the
same as Asterisk uses for sound files. You set the LANGUAGE channel variable
to something like en_US_nyc, for instance, to use a native english speaker
from New York City.

When the system needs a SayScript, say, for a number (%n), it will first
look
for language/en_US_nyc. If no such file exists, or the number script isn't
present,
then it looks again in en_US.  If still not found, it resorts to looking in
en.

So, you could define all the scripts in the en file, put the money script
in en_US,
and use en_US_nyc for a few special utterances that would be uniquely "New
York", those
mostly in translation/en_US_nyc.

As it is, I use lang_locale[_sublocale[_subsublocale[...]]]
notation only because it seems like a good way to organize this sort of
thing, and gives us a good
hierarchical override mechanism, and allows sharing common code. It
wouldn't matter
to me if you set LANGUAGE to "naugahyde" to have everything pronounced in
ancient Latin and every
variant of ancient Latin (dog Latin, or whatever?) have its own separate
"name".

It might even be that you might want to make different voices available for
the same
locale, in which case, you might set it up as sublocales:   fr_FR_jacques
vs  fr_FR_lisa

It could be that you wish to customize a sound set just for yourself, or
for those
who dial you specifically:  en_US_murfwildcrazy.

Right now, for testing, all the requests are for en_testing. In the
translation dir,
I have en_testing with some mappings in it for testing purposes. But in the
language
dir, I have only the en file at the moment. The engine will never find
SayScripts in language/en_testing,
(because the file doesn't exist)but it will back up and find them in en. It
will find the translations in translation/en_testing, and will use them
from there (if they match).

Now, en has to have all the scripts present, because it is a special case;
it is used as the default
for all languages. If you can't find a SayScript anywhere else, there
should be SOMETHING in language/en.

Plus, if you need to write a new sort of SayScript, you can, and use an
unassigned %-char combo to
represent it. For example, if you only want to pronounce a number with 2
digits of accuracy, (when over say, 9999), you could write a %N (I *THINK*
capital-N is unassigned at the moment) Sayscript that would say something
like
"approximately 1.4 million" or, "approximately 7.5 billion ", or whatever.

Hopefully the locale system has enough to do what needs to be done.

Right now, no-one uses anything like %m for pronouncing an amount of money.
The say_* routines don't include it.
Everyone who specifically wishes to pronounce a sum of money has to hard
code "<you have>%n<dollars><and>%n<cents>"
into their IVR's, with the proper variables set up in the dialplan. The %m
is mainly for convenience and shorthand.
But the locale issue doesn't disappear when you do this, you still have to
hard code it by hand into your IVR's.

Sorry, I've rambled on a bit too much, I'm just wanting to make sure
everyone understands the principles.

I haven't defined any concrete rules for how I/we need to organize the
lang_locale files, I'm sure some spec could be developed. I'm only set up
really to define a starting point for en and en_US, and use the current set
of recorded files in the sound files that come with Asterisk. I can help
native speakers remake the language stuff in Asterisk, to work in the
SaySentence/SayScript/SoundPack regime.

murf

--
> Andreas Sikkema
>
>
-- 

Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉  murf at parsetree dott com
☎ 307-899-5535
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131130/dad18d8f/attachment.html>