|Summary:||ASTERISK-06796: [patch] enable multiple voicesets for other languages than 'en'|
|Reporter:||Michel Koenen (michelk)||Labels:|
|Date Opened:||2006-04-17 11:12:11||Date Closed:||2006-05-30 16:38:18|
|Environment:||Attachments:||( 0) say.c.diff.txt|
|Description:||It is possible to set different languages like 'female' or 'male' but then they will use the english way of date/time formats. For other languages, like in my example 'nl', it is only possible to use one voiceset with correct date/time pronounciation by setting the language to 'nl. I want to expand this to unlimited voicesets per language which use the language specific date/time formats.|
****** ADDITIONAL INFORMATION ******
The new say.c will understand language specicification like:
nl_male or nl_female , both will use the 'nl' date/time formats when using apps like Saynumber et cetera.
My current patch is only done for 'nl' but when the idea is accepted in the codebase, I will create the patch for all languages which are addressed in say.c
|Comments:||By: Joshua C. Colp (jcolp) 2006-04-17 13:01:49|
Why don't you just do a strncasecmp of 2 for the first 2 letters? With careful ordering to check for specific ones like en_GB ahead of en, it would work.
By: Michel Koenen (michelk) 2006-04-17 14:38:12
Well, I want to keep it backwards compatible. E.g. when somebody currently uses a language "ploop", which behaves now like the english date/timeformat, and I would use a strncasecmp of only the first two letters, then the language would behave like 'pl' (polish). So then it would not be backwards compatible anymore. I know that the chance that somebody uses "ploop" is very small but there is a very good chance that the first two letters of current languagenames can be the same as one of the build in 2-letter language codes. So using an underscore as language code separator was my solution to be both backwards compatible as well as expanding the possible voicesets for specific languages.
By: Michel Koenen (michelk) 2006-04-26 04:59:58
I wonder how long it can take, or what I have to do to get somebody accept (or reject) this change request ?
By: Serge Vecher (serge-v) 2006-05-09 13:08:18
MichelK: patches that implement new features commonly get stalled in the bug-tracker because they need more realtime discussion, something a BT is not good for as a medium.
I would suggest that you take advantage of the following venues to discuss this with the rest of development community.
1. #asterisk-dev channel on IRC.
2. Weekly conference calls on Tuesdays (see asterisk.org under Developers)
3. asterisk-dev list (see lists.digium.com).
Thanks for your contribution.
By: Michel Koenen (michelk) 2006-05-23 17:21:35
Thank you for your feedback. I posted it here because this was the way how to do it as I did read in several documents.
I didn't try your suggestions 1+2 because yet because I live in another timezone. Will try the dev list then. It's kind of pity because I like this issue tracker because it shows exacly what has been done or discussed on specific topics. I think this is not possible in irc or dev-list.
By: Serge Vecher (serge-v) 2006-05-24 08:36:47
MichelK: some developers on IRC channels are in European or other non-American timezones. So go ahead and try :) The bugtracker is a very useful tool, just not good enough for discussing new features ...
By: Michael Jerris (mikej) 2006-05-30 16:38:18
closed at OP request