<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 30, 2013 at 5:52 AM, Andreas Sikkema <span dir="ltr"><<a href="mailto:h323@ramdyne.nl" target="_blank">h323@ramdyne.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 29/11/13 06:03 , Steve Murphy wrote:<br>
<br>
> Tzafrir, as far as I know, the locale files are THE place to put such<br>
> locale specific information.<br>
> This is no departure from the system of organization presented by GNU<br>
> gettext, and is in use for<br>
> hundreds of languages in even more locales. The language pack is exactly<br>
> tailored for a specific locale.<br>
<br>
</div>Locale and language should not be mixed. In the Netherlands it's quite<br>
common to have both English (en_EN) and Dutch (nl_NL) languages<br>
available in IVR's, but we wouldn't dare (be allowed) to announce<br>
pricing in pounds.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">So, you'd have to put the different money routines<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
in en_NL, and nl_NL, I might imagine.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In the US Spanish (which one) and English (en_US) are quite common, but<br>
you wouldn't announce pricing in dollars and pesetas, they should both<br>
be dollars.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Same here, make sure to put the money routines in es_US,<br>and en_US.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There's load of examples where locale and language are not hard linked,<br>
so linking them in a language pack is IMHO a bad idea. The problem is of<br>
course that this, thinking it through, would require every language to<br>
be able to handle *all* supported locales. There is room for<br>
optimisation, but there might always be a few people complaining about<br>
missing Japanese support for the Zimbabwe locale...<br>
<span class=""><font color="#888888"><br></font></span></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">I think, if we understand each other correctly, I have to <br>
agree with you. A proper language pack will include locale<br>specific utterances under a lang_locale sort of set of files, at least<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
if it's any good. Don't make the mistake that just because my infant <br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">code doesn't have an en_US or en_GB with the right localizations in it,<br>
that I don't intend to provide them! </div> <div class="gmail_default" style="font-family:courier new,monospace;display:inline">But even if I were foolish enough to<br>insist on NOT providing them, and supplying only a dollar specific<br>
money sayscript at the language level, you can always override it in<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">a lang_locale file, and make sure the LANGUAGE gets set up for users<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">as "lang_locale", instead of just "lang".</div></div><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
As it stands, a language pack could have any number of <br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">locale related files in it, hopefully related to a single <br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
language (to more easily organize things).</div> </div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">The issues that separate the locales could be currency, different<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">pronunciation (like accents), vocabulary, who knows. It's up to the<br></div><div class="gmail_default" style="font-family:courier new,monospace">
sound pack provider to provide as many locales as they want/need. If<br>that's not good enough, anyone is always welcome to put together the<br></div><div class="gmail_default" style="font-family:courier new,monospace">
missing locales for a language. If no one is willing to do the work,<br></div><div class="gmail_default" style="font-family:courier new,monospace">then you get what you get.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
BTW, the algorithm to find SayScripts (or translations) is about the<br></div><div class="gmail_default" style="font-family:courier new,monospace">same as Asterisk uses for sound files. You set the LANGUAGE channel variable<br>
to something like en_US_nyc, for instance, to use a native english speaker<br></div><div class="gmail_default" style="font-family:courier new,monospace">from New York City.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
When the system needs a SayScript, say, for a number (%n), it will first look<br></div><div class="gmail_default" style="font-family:courier new,monospace">for language/en_US_nyc. If no such file exists, or the number script isn't present,<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">then it looks again in en_US. If still not found, it resorts to looking in en.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
So, you could define all the scripts in the en file, put the money script in en_US,<br></div><div class="gmail_default" style="font-family:courier new,monospace">and use en_US_nyc for a few special utterances that would be uniquely "New York", those<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">mostly in translation/en_US_nyc.<br><br></div>As it is, I use lang_locale[_sublocale[_subsublocale[...]]]<br><div class="gmail_default" style="font-family:courier new,monospace">
notation only because it seems like a good way to organize this sort of thing, and gives us a good<br>hierarchical override mechanism, and allows sharing common code. It wouldn't matter<br>to me if you set LANGUAGE to "naugahyde" to have everything pronounced in ancient Latin and every<br>
variant of ancient Latin (dog Latin, or whatever?) have its own separate "name".<br><br><div class="gmail_default" style="font-family:courier new,monospace">It might even be that you might want to make different voices available for the same<br>
locale, in which case, you might set it up as sublocales: fr_FR_jacques vs fr_FR_lisa<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">It could be that you wish to customize a sound set just for yourself, or for those<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">who dial you specifically: en_US_murfwildcrazy.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">Right now, for testing, all the requests are for en_testing. In the translation dir,<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">I have en_testing with some mappings in it for testing purposes. But in the language<br></div><div class="gmail_default" style="font-family:courier new,monospace">
dir, I have only the en file at the moment. The engine will never find SayScripts in language/en_testing,<br>(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).<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace">Now, en has to have all the scripts present, because it is a special case; it is used as the default<br>for all languages. If you can't find a SayScript anywhere else, there should be SOMETHING in language/en.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace">Plus, if you need to write a new sort of SayScript, you can, and use an unassigned %-char combo to <br></div><div class="gmail_default" style="font-family:courier new,monospace">
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<br></div><div class="gmail_default" style="font-family:courier new,monospace">"approximately 1.4 million" or, "approximately 7.5 billion ", or whatever.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">
Hopefully the locale system has enough to do what needs to be done.<br><br></div>Right now, no-one uses anything like %m for pronouncing an amount of money. The say_* routines don't include it.<br><div class="gmail_default" style="font-family:courier new,monospace">
Everyone who specifically wishes to pronounce a sum of money has to hard code "<you have>%n<dollars><and>%n<cents>"<br></div><div class="gmail_default" style="font-family:courier new,monospace">
into their IVR's, with the proper variables set up in the dialplan. The %m is mainly for convenience and shorthand.<br></div><div class="gmail_default" style="font-family:courier new,monospace">But the locale issue doesn't disappear when you do this, you still have to hard code it by hand into your IVR's.<br>
</div><br></div><div class="gmail_default" style="font-family:courier new,monospace"><div class="gmail_default" style="font-family:courier new,monospace">Sorry, I've rambled on a bit too much, I'm just wanting to make sure everyone understands the principles.<br>
</div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br>
<br></div>murf<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888">
--<br>
Andreas Sikkema<br>
</font></span><div class=""><div class="h5"><br clear="all"></div></div></blockquote></div><br>-- <br><div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br>57 Lane 17<br>Cody, WY 82414<br>✉ <a href="mailto:murf at parsetree dott com" target="_blank">murf at parsetree dott com</a><br>
☎ 307-899-5535<br><br><br></div>
</div></div>