I m trying to develop a vxml app to play a welcome prompt with names.
for example "Hello Mr Karthikeyan.. welcome to stackoverflow helpline..."
I want system to voice out the name without spoiling the User Experience..
is there any the possible values for interpret-as/format attribute of < say-as > tag in Nuance Platform? something like ?
There are no say-as or interpret-as attributes that will help with proper names. To fine tune the Text-To-Speech (TTS) engine for proper names you will need to update the TTS dictionary with the names that will be voiced back and the proper pronunciation. Nuance sells some packages that can update their TTS dictionary with a large list of common names.
Related
My team supports a mobile app that is offered in several languages. I asked the team to implement AccessibilityIDs so that I can run Appium tests, which they did. (Why did I ask this? Because everyone in Appium testing is conveying that this is the best approach.)
Later - testing of the app's real world accessibility (using assistive technology - aka talkback or screenreader) revealed that using contextual information is desired. For example, if a button has text "Submit your order" ideally the Accessibility ID should be "Submit your order" not something like "form_page_submit_button"
The team brainstormed and the solution was to create a lang file for an obscure language that we don't plan to support. We settled on "pt-PT" so all the elements could have an accessibility ID that was not likely to change for some time.
This is now becoming a problem as I would like to have visual automated tests in English and French, not just Portuguese, and I am hoping to not have to maintain xpaths with ORs in it. For example, //*[contains(text(),'Submit') or contains(text(),'Soumettre')] ie, English and French.
In light of the fact that my app needs to be accessible to users more than it needs to be accessible for test script, I am evaluating which element selector strategy to recommend going forward. I am prepared to recommend using ID or name to alleviate this issue, but would like to get more thoughts on what others are doing in this space.
Going with ID's and names sort out the situation as mentioned in this answer.
If you like to use the XPath then you can use a dictionary variable to store the text based on the region i.e. [EN='Submit', FR='Soumettre'] and set the locators with the text-based on the region by using the dictionary values using the region as key and appending the text to the locator i.e. framing the locator dynamically based on the region might work out.
As I worked on Robot framework, using some piece of code to depict it and using collections and string library of robot framework
*** Variables ***
${region} EN #set this var as per region
${loc} xpath = //*[contains(text(),'replace_text')
&{submit_loc_text} EN=Submit
... FR=Soumettre
*** Keywords ***
implementation
${text_asper_region} Get From Dictionary ${submit_loc_text} ${region}
${loc} Replace String ${loc} replace_text ${text_asper_region}
Set Test Variable ${loc} ${loc}
If you still prefer to use accessibility ids and support all languages, I would suggest to create interface for every language to get the relevant accessibility locators. This will be easy to understand and maintain ofcourse efforts will be little more but I think it will be worth.
Do anyone know if it is possible to localise a TWINE game? I’d like to have my interactive stories in all the Scandinavian languages. I also plan to have mp3 spoken narration in each language for non-readers at a later stage. My thought was to maybe have one complete story file per language but it seems like a hard thing to maintain.
Do anyone have a best-way of doing this?
It may be possible to localize your Twine game's default UI strings, depending on your story format. For example, if you're using the SugarCube v2 story format in Twine, then there are some SugarCube localizations here.
However, for your story text it's entirely up to you how you handle displaying that based on the user's choices. Again, assuming you're using SugarCube, you might have the user select the language in the beginning like this:
<<set $lang = "EN">>
''Select your language:'' <<listbox "$lang" autoselect>>
<<option "English" "EN" >>
<<option "русский" "RU">>
<<option "українська" "UK">>
<<option "Türkçe" "TR">>
<</listbox>>
That will give you a dropdown list of language options.
Then, in each of your passages, you would have something like this:
<<switch $lang>>
<<case "RU">>
(Russian version of passage.)
<<case "UK">>
(Ukranian version of passage.)
<<case "TR">>
(Turkish version of passage.)
<<default>>
(English version of passage.)
<</switch>>
You could put any non-language based code outside of that "switch" macro.
If you're using something other than SugarCube for your story format, then you'll likely use something similar to that.
Hope that helps! :-)
I'm using Sphinx4 version 4-1.0beta6 over my mac osx 10.9.1 through the terminal.
I'm still new in this SR application. I've already run HelloWrold example and added some new words to the gram file and it worked. Now, I'd like to use rules or something that helps in order to accept more sentences spoken by the user. My questions are:
How Can I make my HelloWorld do that? Should I use rules? and if so, is there any examples?
If I used rules, How can I print the spoken question back to the user?
Thanks in Advance.
How Can I make my HelloWorld do that? Should I use rules? and if so, is there any examples?
It depends on the task but generally you want to extend the grammar with more rules. You can find more information in CMUSphinx tutorial at http://cmusphinx.sourceforge.net
If I used rules, How can I print the spoken question back to the user?
You get the recognition result as string. You can print it with System.out.println or display in your UI or do whatever you want.
I want to integrate an English dictionary function into my Windows Phone 7 application. Is there such a file or database available somewhere that contains all valid English words?
By the way, I only need something containing the list of words in order to validate inputs made by users. Other things such as definitions, phonetics, thesauruses, etc... are not needed.
Try this link (text file). It obviously doesn't have all valid words, but it should be reasonably effective.
The spell check API that's integrated isn't exposed to developers, so you'll have to make do with a text file like this.
Also, if you only need to check the validity of the word that the user enters in a text input of some kind, then all you need to do is set InputScope="Text" in the XAML declaration.
Hope this helps.
I am developing a ERP software inhouse and one of the requests is to have the the username of the person creating any document to appear on the window title when that document is opened.
It will be something like [USR] - Transport Order 123456
Are there any usability rules that I am not adhering to by doing this? It just looks a bit unprofessional to have [] in the window title.
Any ideas?
There's nothing wrong with that at all. As a matter of fact, many of the biggest ERP applications do similar things.
In my opinion, though, the first part of the title should either be the name of the application or the name of the window. Anything else should go after that. It just makes it easier to read.
Something like this, maybe:
ApplicationName - Transport Order 123456 - UserName
Both the Windows UX Guidelines and Apple HIG have rules for naming windows. However, the specific rules are oriented towards document-type applications rather than database-type applications like ERP. Nonetheless the general principles apply.
The primary purpose of the window title is to make it easy for users to distinguish their windows. For this reason both Windows UX Guidelines and Apple HIG recommend windows be titled by their content, since that is usually what users will be looking for to choose a window to click on. Other potentially useful information, like the program name, may follow the content identity. The Windows UX Guidelines, for example recommends a “document name – program name” format (p316). You want the most distinguishing information first in the title so it's easiest to see, especially when looking at the task bar for which the name is often truncated. Also, the icon represents the program identity, so the program name is a little redundant anyway.
Multi-window ERP apps likewise should distinguish their windows by their content. Thus generally, the title should start with the window name, identifying the class of data shown in the window, followed by any filtering or querying criteria of the data. This order assumes users are more likely to have open two different windows than two instances of the same window with different filtering criteria. The title may end with the program or application name, if you think it’s necessary. So an example title would be something like:
Shipments (Ship Date: 2008-01-01 to 2010-01-01) ERP-O-Rama
It may be helpful to include the user who created or "owns" the data if that is different than the user currently looking at the data, but that still doesn't sound like something that distinguishes windows -are users going to be looking two different versions of the same content created by two different users? It seems at best to be secondary information to put at the end of the title if there at all. Why do users need to know this? Perhaps it should be a field in the window or a property in a Properties dialog.
You certainly don't need the current user's name in the title, unless users can be simultaneously logged in under different identities (e.g., they’re Jakob Nielsen for one window but Jared Spool for another). Users generally know who they are, so it seems like unnecessary clutter to me. If users may be logged in as different users or roles for different sessions (which is generally not a good idea) then you may want to represent that in the status bar, but not the title bar.
Brackets vs. parentheses vs. dashes seem like a matter of taste to me. Windows generally prefers em-dashes. My only advice is to use them only when necessary to delimit substrings. "[USR]" doesn't seem appropriate unless there may be spaces in the username.
Do your users care if you break a "usability rule", so long as what you do makes the program more usable? That is, if putting the username in the title enhances usability for your specific users, strict adherence to some standard comes secondary.
Put the needs of your user first. If putting the user's name in the title bar enhances usability, by all means do it.
I recommend something like
123456 - Joe User
The square brackets aren't necessary, and neither is the phrase "Transport Order" unless you need them for disambiguation.