On Sat, Nov 30, 2013 at 5:52 AM, Andreas Sikkema <h...@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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev