bkml wrote:
> as part of the conversion to property lists I will work on a voices &
> prompts database.
>
> This would look like the following ...
>
> // voices in which recordings of prompts are available
> voices = {
> Allison = {
> fullname = "Allison Smith";
> type = human;
> gender = female;
> locale = US-English;
> // subdirectory within SOUNDS_DIR
> subdirectory = allison;
> };
> };
Please consider using the more widespread ISO639 two letter language
codes to describe the locale, eg. en_US, instead of US-English. See
http://www.loc.gov/standards/iso639-2/
> For example, a caller with a UK caller ID could automatically be
> played all prompts in one of the available UK accents without having
> to rewrite the dialplan. It would also make IVR scripting with
> interleaved use of male and female voices easier.
This scheme would rely being able to accurately identify the geographic
origin of a call, which in some cases may be presumptuous. I think at
the moment it is simpler to just set the channel language variable. That
in itself however, needs to be expanded from the current two letter
language code to a full locale code.
> Even worse, the current code base only works within a rather narrow
> concept of grammar. Languages which don't fit that concept cannot be
> supported properly without architectural changes to the code base.
Yes, it is clear that Asterisk was never designed to be multilingual.
From what I've seen, additional code for regional differences has gone
into apps like voicemail as hard-coded changes. This is not a scalable
solution. Even just the different between English and German highlights
the need for a more flexible phrase builder:
en: You have twenty four new messages.
de: Sie haben vier und zwanzig neue Nachrichten.
Note the difference in reading out numbers over 20 - "four and twenty"
in German. Also, many languages other than English change the article,
depending on the gender of the noun, and more importantly in our case,
whether we are talking about a plural or not.
> Basically, the tenor was "This is not how Asterisk works, you will
> have to get the Japanese language changed" paraphrasing OEJ.
Come on, be reasonable, see it my way ;-)
> So, yes, this needs to be sorted out, but it is not trivial, it will
> require some serious work.
No, it is certainly not trivial to teach a computer about natural
languages. Perhaps we should decide whether we attack this is two steps.
Firstly, just implement slightly smarter handling of what is already in
the code, by adding the locale support to the existing simple language
support. Then, attempting to strip out hard-coded regional code, and
express that somehow in a language template file similar to what you
propose.
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
