jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul P Akolkar <akol...@us.ibm.com>
Subject RE: RDC: grammar tags in the state component
Date Wed, 23 Feb 2005 16:42:03 GMT
 > I'm not a VUI expert, but the idea of having this
> initial grammar seems like a fine idea.  I'd think
> the biggest issue is providing enough flexibility
> so that people can customize it. It's inevitable
> that users are going to want to have control over
> this.  If for nothing else, localization; but also
> for changing the utterances that can be used and
> also doing regional tuning.

Very true. Looking at the RDC tag library from an i18n perspective, let me 
identify the resources that are locale specific, and the action items:
1) Prompts - Since we already have the mechanism (and necessary 
separation) for specifying the prompts associated with any RDC instance in 
terms of a config file, localizing the prompts is simply providing an 
appropriate config.
2) Grammars - The component grammars defined in the tag files which are 
static URI references need to be updated with locale specific URIs read 
out of resource bundles.
3) Loose ends - Embedded grammars and error messages. I think the only 
instance of an embedded grammar is the initial grammar, though I'll double 
check. Error messages produced in the org.apache.taglibs.rdc.dm package 
need to change similar to (2).

I will begin to work on the i18n, starting with (2), then (3). I'll set 
things up so the grammar URIs are locale specific, but I lack the ability 
to translate ;-) We will need volunteers to do the actual translation.

> As a follow up question, do you mind pointing me to
> the location within the code that generates this 
> dynamic grammar?


As per discussion above, it won't stay there for long.

Can you also let me know what fails with the Nuance engine? Does it 
require an xmlns attribute on the embedded grammar? I think I noticed that 
with the Cisco browser. At some point, we will have a build switch, so 
these "platform adaptations" can be done by specifying the platform as a 
build property. Also, do let me know if you are aware of a good 
compilation of platform "quirks" for various platforms. That will be a 
good starting point for this exercise.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message