On Mar 5, 2006, at 6:33 PM, Daniel Swarbrick wrote:
> 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/
A friend of mine who is a lawyer is a founding member of something
called the Royal British Society for Promoting the Use of Plain
English in Law Text, or similar.
I cannot overstate how much I respect him for that fact alone.
If anybody wants to start the Royal British Society for Promoting the
Use of Plain English in Computer Software, I'll volunteer as a
founding member in a heartbeat.
So I say, let the software translate the terms internally. This stuff
is read only once at startup, so there's no performance tradeoff.
That way, ordinary people will be able to use a front-end to choose
their locale without even knowing what a locale is and they can even
read and understand the database file.
>> 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.
Well, it was just one example of what kind of applications are
possible once the system has access to meta data about the recordings.
> 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.
The approach of gradual change seems to be our best choice by default
since we don't really have the resources to go about any major
rewrite in one go ;)
regards
benjk
___________________________________________________________
Win a BlackBerry device from O2 with Yahoo!. Enter now.
http://www.yahoo.co.uk/blackberry
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
