Language Handling: call for assistance
Hello all! There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Hi, Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian? Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do? What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Sorry if I miss understood something. Cheers, -- Igor Neves <igor.neves@3gnt.net> 3GNTW - Tecnologias de Informação, Lda SIP: igor@3gnt.net JID: igor@3gnt.net ICQ: 249075444 MSN: igor@3gnt.net TLM: 00351914503611 PSTN: 00351252377120
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves <igor@3gnt.net> wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus, just to be sure.
From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Sorry if I miss understood something. Cheers,
Believe, the moment we put this into place we will have someone purporting to be an expert offering a completely new solution. That's why we asked for input now, before Tony spends a lot of time working on it. -MC
sound prefix should not be used for lang just "language" the sound_prefix is automatically built as ${base}/sounds/${language}/ each time you execute say. and restored to its previous val when the say is over. On Thu, Jul 2, 2009 at 12:07 PM, Michael Collins <msc@freeswitch.org> wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves <igor@3gnt.net> wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus, just to be sure.
From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Sorry if I miss understood something. Cheers,
Believe, the moment we put this into place we will have someone purporting to be an expert offering a completely new solution. That's why we asked for input now, before Tony spends a lot of time working on it. -MC
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Michael Collins wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves <igor@3gnt.net <mailto:igor@3gnt.net>> wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus, just to be sure.
>From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Sorry if I miss understood something. Cheers,
Believe, the moment we put this into place we will have someone purporting to be an expert offering a completely new solution. That's why we asked for input now, before Tony spends a lot of time working on it. -MC
The PT_pt format is for written languages, rather than spoken languages. There is often a difference. The SSML 1.1 spec references http://www.ietf.org/rfc/bcp/bcp47.txt as a definition of how to identify a language and accent for speech. I'm not clear if its really works, though. Steve
On Fri, 2009-07-03 at 01:29 +0800, Steve Underwood wrote:
Michael Collins wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves <igor@3gnt.net <mailto:igor@3gnt.net>> wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus, just to be sure.
>From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Sorry if I miss understood something. Cheers,
Believe, the moment we put this into place we will have someone purporting to be an expert offering a completely new solution. That's why we asked for input now, before Tony spends a lot of time working on it. -MC
The PT_pt format is for written languages, rather than spoken languages. There is often a difference.
The SSML 1.1 spec references http://www.ietf.org/rfc/bcp/bcp47.txt as a definition of how to identify a language and accent for speech. I'm not clear if its really works, though.
Steve
I think that would be overkill. The usual way of using i.e. "pt-br" (two letters for the main language, dash and then two more letters for the dialect/variation) would be enough. Regards, Raul
On Thu, 2009-07-02 at 15:47 -0300, Raul Fragoso wrote:
On Fri, 2009-07-03 at 01:29 +0800, Steve Underwood wrote:
Michael Collins wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves <igor@3gnt.net <mailto:igor@3gnt.net>> wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus, just to be sure.
The <lang>-<dialect> thing would appear to be the obvious choice; what's slightly less obvious is what to do about fallback. Three choices: - None - i.e. I say en-gb, I either get en-gb or nothing; - Best guess - I want en-gb, but I'm quite happy with en-us or en-au. I could specify en-gb and, if en-gb's not available but en-something else is, whatever's available gets chosen for me; - Preference list - I specify a (possibly) wildcarded list of what I want - e.g. en-gb,en-us,en* - and whichever match comes first is what I get. --Dave -- David Knell, Director, 3C Limited T: +44 20 3298 2000 E: dave@3c.co.uk W: http://www.3c.co.uk
Raul Fragoso wrote:
On Fri, 2009-07-03 at 01:29 +0800, Steve Underwood wrote:
Michael Collins wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves <igor@3gnt.net <mailto:igor@3gnt.net>> wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple languages, specifically with the *say* application. We would like some input from the community on how to handle multiple languages and sound files. Anthony notes that the say application needs to build the path to the sound files by using the ${sound_prefix} and ${lang} variables. Some have asked about countries or language variants, like European Portugese vs. Brazilian Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use "PT_pt" and "PT_br" in ${lang}, just like a lot of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus, just to be sure.
>From the community we need input. If you have experience with multiple languages in a telephony environment then please give us your suggestions. How would you like to see the say application handle various languages and dialects? Please give us your helpful suggestions.
Thanks, Michael
Sorry if I miss understood something. Cheers,
Believe, the moment we put this into place we will have someone purporting to be an expert offering a completely new solution. That's why we asked for input now, before Tony spends a lot of time working on it. -MC
The PT_pt format is for written languages, rather than spoken languages. There is often a difference.
The SSML 1.1 spec references http://www.ietf.org/rfc/bcp/bcp47.txt as a definition of how to identify a language and accent for speech. I'm not clear if its really works, though.
Steve
I think that would be overkill. The usual way of using i.e. "pt-br" (two letters for the main language, dash and then two more letters for the dialect/variation) would be enough.
If by "the usual way" you mean the standard 2 + 2 letter codes we are used to on computers, that just doesn't work. As I said before, those are for written languages, not spoken languages. There are no standard codes for many spoken languages. For example, the standard codes for Chinese are zh_cn for mainland China, zh_tw for Taiwan, zh_hk for Hong Kong. However, in GuangDong you will probably want to offer Cantonese as well as Mandarin voice prompts, so you will want a zh_gd, or something, which you won't find among the standard 2 + 2 letter codes. That's why the SSML people had a hard time coming up with a language scheme, and SSML 1.0 didn't even reference one. The more you look around the world, the most complex the issue of language variants becomes. If you don't face that at the beginning it just gets messier later on. Steve
On Jul 2, 2009, at 7:50 PM, Steve Underwood wrote:
If by "the usual way" you mean the standard 2 + 2 letter codes we are used to on computers, that just doesn't work. As I said before, those are for written languages, not spoken languages. There are no standard codes for many spoken languages. For example, the standard codes for Chinese are zh_cn for mainland China, zh_tw for Taiwan, zh_hk for Hong Kong. However, in GuangDong you will probably want to offer Cantonese as well as Mandarin voice prompts, so you will want a zh_gd, or something, which you won't find among the standard 2 + 2 letter codes. That's why the SSML people had a hard time coming up with a language scheme, and SSML 1.0 didn't even reference one. The more you look around the world, the most complex the issue of language variants becomes. If you don't face that at the beginning it just gets messier later on.
Steve
Do we know that the language model at least always pairs with the first 2 letter code? So zh_* we can use mod_say_zh for? or do we need to address different language rules for different dialects as well? Mike
Guys, I don't know if I really get the problem here. I mean, I do get that the 2+2 model does not work not even for where I live. I really hate the fact that all spanish south american dialects (some within the same country) are put in the same bag as it wouldn't matter to ppl so I am with you Steve on this one to find an alternative to the 2+2 model. So, in summary, what I am asking is: What would be the problem with mod_say_es_ar_ba for Porteño dialect spoken in Buenos Aires, Argentina besides the verbosity of it and the limited amount of "levels" we have? Do we know any country that has a sub-dialect from a dialect? jmesquita PS: Please, forgive me if I totally misunderstood it. Afterall, I do have I high fever. On Thu, Jul 2, 2009 at 8:58 PM, Michael Jerris <mike@jerris.com> wrote:
On Jul 2, 2009, at 7:50 PM, Steve Underwood wrote:
If by "the usual way" you mean the standard 2 + 2 letter codes we are used to on computers, that just doesn't work. As I said before, those are for written languages, not spoken languages. There are no standard codes for many spoken languages. For example, the standard codes for Chinese are zh_cn for mainland China, zh_tw for Taiwan, zh_hk for Hong Kong. However, in GuangDong you will probably want to offer Cantonese as well as Mandarin voice prompts, so you will want a zh_gd, or something, which you won't find among the standard 2 + 2 letter codes. That's why the SSML people had a hard time coming up with a language scheme, and SSML 1.0 didn't even reference one. The more you look around the world, the most complex the issue of language variants becomes. If you don't face that at the beginning it just gets messier later on.
Steve
Do we know that the language model at least always pairs with the first 2 letter code? So zh_* we can use mod_say_zh for? or do we need to address different language rules for different dialects as well?
Mike
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (8)
-
Anthony Minessale
-
David Knell
-
Igor Neves
-
João Mesquita
-
Michael Collins
-
Michael Jerris
-
Raul Fragoso
-
Steve Underwood