<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 28, 2013 at 1:58 PM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir.cohen@xorcom.com" target="_blank">tzafrir.cohen@xorcom.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Nov 26, 2013 at 10:04:58PM -0700, Steve Murphy wrote:<br>
</div><div class="im">> Hello--<br>
><br>
> Boy, it's been a long time since I posted to the dev mailing list!<br>
><br>
> I'd like to announce a proposal to the Asterisk Community, that I<br>
> introduced at Astridevcon last month. It is a new API for playing sound<br>
> files (mainly speech). A pdf describing the Proposal in some detail is at:<br>
><br>
> <a href="http://www.gmvoices.com/downloads/steve/sayscripts.pdf" target="_blank">http://www.gmvoices.com/downloads/steve/sayscripts.pdf</a><br>
<br>
</div>First example:<br>
<br>
* ret = ast_say_sentence(chan, “#*”, "<you_transferred> %m <to_your_account> %[o]d", balance, transaction_date);<br>
<br>
%m should be "money". At what currentcy? When I say this in French<br>
should I still say Dollars, or should it be Euros? And what currency<br>
for Spanish?<br>
Furthermore, you require the currency to be mmm.nn (exactly two 'cents'<br>
digits). Some currentcies (e.g. the Yen) have no 'cent'. I believe that<br>
some have a 'mil' (but I can't think of any off the top of my head.<br>
<br>
</blockquote><div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Here's the global view. You set your locale string for the LANGUAGE variable on the channel. In the default case, the language is set up to be "en" by default. If you are set up to use the SaySentence stuff, your sayscripts are in /var/lib/asterisk/language/en. Now, I suppose, to be more technically correct, there should be en_US, and en_GB, or any of the other locales for english speakers. Right now, the en sayscript is pretty much en_US. Thus, the dollars and cents, and the expectation that the money value end with .xx. At some point, we'll put together the en_GB sayscripts, and they will be pounds or Euros or whatever, and do the right thing for the Brits.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">But, if the channel is set up for de or fr or es, or any other language, the code will search for that file and use its sayscripts, which might pronounce Euros, or Yen, or rubles, or whatever, and might not expect any .xx at the end.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Now, there are a lot of countries that speak Spanish. Each has its own currency. But the ability to say the right currency in the right way, should all be in the SayScript for that locale, whether it be es_ES, es_MX, or whatever.<br>
<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The currency seems to me a rather local decision and should not be part<br>
of the code or of the language pack.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Tzafrir, as far as I know, the locale files are THE place to put such locale specific information.<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">This is no departure from the system of organization presented by GNU gettext, and is in use for<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
hundreds of languages in even more locales. The language pack is exactly tailored for a specific locale.<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
>From what I understand, the sound set should include "you transferred"<br>
and "to your account".<br>
<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Agreed.<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Anyway, you'll now need to go and fix each and every sound set for<br>
Asterisk. This includes each and every sound set in a supported language<br>
(such and English and Spanish).<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">No, my plan is to just convert the code in say.c to SayScript, and have it use the same sounds<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">in the same way, for each locale, even if it isn't correct. But that's up to the guys making those sound packs. Let's face it, not all the languages provide overrides for all the sounds, and not all are completely correct. If (for example), the folks doing the Greek translation spot an error, or an ommission, they are free to add, or correct sound files at their discretion.<br>
</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The really funny thing would be to have buggy sound sets. But why would<br>
you rely on code that is included with something that should only<br>
include data? For instance, REASTART at the right place could induce an<br>
endless loop, right?<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">I honestly don't understand your reasoning here, as to "that should only include data". The reason why, is because I don't see the current Asterisk code and sound sets being completely independent of each other. They are not. The code calls out those files to play, and without the code, no sound files would be played at all. Those algorithms, in the Asterisk source code, are an integral part of the game. If you expect sound packs to only contain sound files, you are ignoring that thousands of lines of code are devoted to each language, and is smeared out in various places in the Asterisk code base.<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Last I counted, say.c has like 8000 lines of locale-specific code. There is a great deal of language-specific code in app_voicemail. There SHOULD be more language specific code in other places, especially where whole sentences containing variables. (Maybe app_voicemail is the only app/res/whatever to speak "complex" sentences, I haven't studied for that).<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">All I know is, that the current situation is insane. There are a LOT of languages out there. And while Asterisk has really only a small number coded, and recorded. To introduce a new language, you need to write a bunch of code. It needs to be compiled into Asterisk. It has to go into trunk, and it could be months or a year before it appears in a release. This is an extremely slow and expensive process. Yes, I remember from long ago, that the community is willing to "streamline" this, but really, look at the history. In the last two years, I have seen very little in new language introduction, even though there is no lack of possible languages to make available.<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline"><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">As to the ability of a sayscript to infinitely loop, yes, at the current moment, it can. But I promise that long before this code goes "production", if it ever does, I will modify the interpreter so that if state does not change in some number of loops, it will force termination with an error. This is a fairly simple change to make.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Can you think of other problems that I might want to watch out for?<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
As to the possible poor quality of the results of a sound pack, well, it applies to all the current sounds in Asterisk: report the problems, or submit fixes, and someone will hopefully refine their sound pack.</div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">
If they don't, don't use them. Make your own. Or whatever.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">If I were to publish submitted soundpacks for general distribution, I might consider writing scripts for basic acceptance. I might require that they parse without error, and contain the all sound files referenced by the SayScripts. I might require some certification that the sound files follow the scripts, and who know what else, to insure some level of quality and sanity. But in the end, it is "buyer beware" sort of situation. End users should test them out before putting them in production.<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline"><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">murf<br><br></div></div></div>-- <br>
<div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br>57 Lane 17<br>Cody, WY 82414<br>✉ <a href="mailto:murf@parsetree.com" target="_blank">murf<div class="gmail_default" style="font-family:courier new,monospace;display:inline">
at </div>parsetree<div class="gmail_default" style="font-family:courier new,monospace;display:inline"> dott </div>com</a><br>☎ 307-899-5535<br><br><br></div>
</div></div>