I have an Apple watch app that works exclusively with English dictation. The reason no more languages are available is a long story so bear with me a while.
I know that doing a "hard press" on the screen, while dictation is going on with the nice voice graph, brings up a "choose language" menu where the user can select one of his available languages to do dictation with.
I want to find out programmatically, which language is currently being used for dictation, so that I can prompt the user to switch to English, if any other language is currently selected.
The menus, and everything on my phone is in English, but I also use German, Catalan and Spanish.
So far, I am using this code:
let language:NSString=NSLocale.preferredLanguages().first!
print("ASR(?) Language: "+(language as String))
But this, in fact, returns the System Language that is set in the main iOS Watch Map: General > Language and Region > System Language, not the Dictation Language.
...and this is the code I use for Dictation:
self.presentTextInputControllerWithSuggestions([], allowedInputMode: WKTextInputMode.Plain, completion:{(results) -> Void in
let aResult = results?[0] as? String
if(!(aResult == nil)){
print(aResult)
print("ASR says: "+aResult!)
}//end if
})//end show voice menu
Is it possible to detect which language is really the one being used for dictation?
Related
I'm new in programming. I can write some Python code and I would like to write some script on a Macbook with the Script Editor.
So what is the best way to learn AppleScript? What material do I need?
I have tried to learn AppleScript with the language guide and Window Anatomy.
But when I tried to read some code, I can't understand many of the statements.
Example:
tell application "System Preferences"
activate
set current pane to pane "com.apple.preference.sound" --I can't understand "com.apple.preference.sound".What's the rule of strings like this?
end tell
tell application "System Events"
tell application process "System Preferences"
tell tab group of window "Sound"
click radio button "output" --There,I don't exactly know what's radio button,pane,table is.
if (selected of row 1 of table 1 of scroll area 1) then
set selected of row 2 of table 1 of scroll area 1 to true
set deviceselected to "外置音响"
else if (selected of row 2 of table 1 of scroll area 1) then
set selected of row 3 of table 1 of scroll area 1 to true
set deviceselected to "LG"
else
set selected of row 1 of table 1 of scroll area 1 to true
set deviceselected to "MAC"
end if
end tell
end tell
end tell
It seems I don't know these concepts outside of the language syntax. How can I learn these things?
The string is a string (a sequence of characters; surrounded by quote marks when written in literal—code—form). The content of that particular string is a Uniform Type Identifier which is just a naming convention, much like domain names in URLs except backwards.
Knowing what the various GUI widgets are called takes a passing familiarity with GUI programming. e.g. Radio buttons are the circular buttons which come in groups where you can pick any one. There is an helpful app for GUI Scripting if you really, really need it. Also, GUI Scripting is a klunky fragile brittle pig and only used as the last resort when apps don’t provide a scripting interface of their own. Which brings us to a more general point…
Knowing what the various types of objects that exist in an AppleScriptable application are called, plus what information they contain and how they can be manipulated with commands, requires reading that application’s AppleScript dictionary (File > Open Dictionary in Script Editor) plus some intelligent guesswork (since app dictionaries are almost always famously inadequate on details). A good AppleScript book will help you to develop that skill, and will save you a lot of head-scratching and time in the long run. (I was lead author on #BernardR’s book #2, btw.)
If you are serious about learning AppleScript, I strongly recommend you get Script Debugger. It is far superior to Apple’s Script Editor not only for exploring application dictionaries but also the live objects within the running application itself. The user-to-user forum there is also good for AppleScript-specific advice.
Lastly, if you are familiar with an Object-Oriented Programming language such as Python, you will find AppleScript uses a lot of the same jargon when talking about scriptable applications: classes, objects, etc. Do not be fooled. Application scripting (Apple event IPC) is not OOP: it is remote procedure calls which pass simple queries as arguments. The queries identify the data you wish a command to operate on (e.g. size of first word of every paragraph of front document) and the command tells the application what to do with whatever data it finds (e.g. set (size of…) to 18). Thus in AppleScript you can perform operations such as:
tell application "TextEdit"
set size of first word of every paragraph of front document to 18
end tell
which is not a concept you can express in OOP; it’s a lot more powerful than that. (BTW, this is why programmers hate AppleScript: because they incorrectly assume application scripting is OOP; then when it behaves in some profoundly non-OOP way it confuses the hell out of them.)
--
p.s. Good Luck. You will need it, as it is awesome and frustrating in equal measure. (Although the awesome parts usually make it worth all the hair pulling it takes in getting there.)
The name of a preference pane is not a part of the AppleScript language.
The authority on the Sound preference pane is /System/Library/PreferencePanes/Sound.prefPane/Contents/Info.plist. There, you can notice
<key>CFBundleIdentifier</key>
<string>com.apple.preference.sound</string>
This is the name of the pane.
You can consult How to know the name of UI elements using Accessibility inspector (or any other tool) and AppleScript – How can I get UI elements' names, attributes, properties, classes programmatically without "guessing" via AccessibilityInspector? to figure out how to know about radio button "output" part.
I can recommend 2 books to learn AppleScript:
AppleScript 1-2-3, A Self-Paced Guide to Learning AppleScript, by Sal Soghoian and Bill Cheeseman
Learn AppleScript, The Comprehensive Guide to Scripting and Automation on Mac OS X (3rd Edition), by Hamish Sanderson and Hanaan Rosenthal
The first book is good for scripting beginners but both books complement each other.
There are many example scripts and the authors of both books discuss key concepts that are fundamental to scripting with AppleScript.
The author of the first book, Sal Soghoian, was for several years Product Manager for Automation Technologies at Apple.
I am new to programming and am trying to design a Fortune Teller game according to a book "Applescript studio programming for the absolute beginner".
When the player types the question in the Text Field and then clicks the "Ask" button, the program will randomly give the answer "Yes" "No" "Maybe".
I did as the book instructed. But when I press build and go in Xcode, it returns "2018-04-08 22:22:01.189 Fortune Teller[14813:245050] *** -[AppDelegate clicked:]: Can’t get every text of TextField of class "NSObject". (error -1728)"
Can anyone tell me how to fix that problem? Thank you!
The following is the interface.
The following is the code.
-- This code runs whenever the player clicks on the Ask button
on clicked_(theObject)
-- Assign the text entered by the player clicks on the Ask button
set the question to contents of text field "textbox" of window "main"
-- Display an error message if the player did not enter any text
if question = "" then
display dialogue ¬
"Sorry, but you did not ask a question. Please try again."¬
buttons {"OK"}
return
end if
-- Assign a random number between 1 and 3 to a variable named random
set randomNo to a random number from 1 to 3
if randomNo = 1 then
set answer to "Yes"
end if
if randomNo = 2 then
set answer to "No"
end if
if randomNo = 3 then
set answer to "Maybe"
end if
beep -- Play a beep sound to get player's intention
display display dialog "Question:" & question & "Answer:" & answer & buttons {"OK"}
end clicked_
Ouch. Get a new book.
Mac OS X 10.6 replaced AppleScript Studio with AppleScript-ObjC. Unlike ASS, which gave you AppleScript-style commands and classes for controlling Cocoa, ASOC is just a thin wrapper around Cocoa’s Objective-C APIs, meaning you need to learn those APIs before you can use it.
Shane Stanley used to have an e-book on GUI programming with ASOC, but I think it’s out of print unfortunately. There was an introductory chapter to GUI programming with ASOC at the end of Apress’s Learn AppleScript, 3rd edition (which I co-wrote), and the AppleScript Users mailing list/MacScripter.net forum can no doubt point you to whatever other resources are out there. But all in all, documentation and support is not great. You pretty much have to learn ObjC in order to use ASOC effectively, even if just to read the Cocoa documentation and translate it to AS syntax in your head. And it hasn’t been updated in several years so lacks support for newer ObjC features such as blocks, which means you end up writing ObjC code anyway if you want to use those APIs.
..
Frankly, if your goal is to write your own GUI Apps (rather than automate existing ones), I strongly recommend you bite the bullet and learn Apple’s Swift. While it’s a bloated mess of a language, it’s well-documented, widely-used, and 100% supported by Apple [unlike AppleScript]. With Apple recently announcing a new GUI framework for writing iOS and macOS apps, it’s clear that Swift is the future.
If you need a bit of AppleScript to talk to other apps, it is possible to mix Swift and AS in the same app; but that’s a different question for a separate post.
I have recently been learning how to program with the Clutter GUI toolkit. One thing I haven't been able to figure out is how to set the programs title and icon for the window manager.
As illustrated in the image below, Gnome Shell says that the program name is "Unknown" and that the program does not have an icon.
So, how do I do this?
you cannot do this from Clutter: the windowing system API inside Clutter only allows basic operations.
if you want proper integration in a windowing system you should use Clutter-GTK, and embed a ClutterStage into a Gtk application.
In theory, you can do that in this way:
let stage = Clutter.Stage.get_default ();
let gdkWind = ClutterGdk.get_stage_window (stage);
// The list most containt icons in different sizes.
let list = [GdkPixbuf.Pixbuf.new_from_file("test.png")];
gdkWind.set_icon_list(list);
//The next line not work
gdkWind.set_title("This title is not added");
In practice, you only will can load the icon and the windows title, but not the task bar title for the windows. The set_title won't work as Gdk.Window reference say it will (https://people.gnome.org/~gcampagna/docs/Gdk-3.0/Gdk.Window.set_title.html). Is then a Clutter issue, because is not a GDK "special case". But well is not working.
How to make the on-screen keyboard use only English, even if the settings are selected some other languages besides English?
Sorry, you cannot change the keyboard language in code on WP7.
Update
I did a bit of research on pulling the current language (Locale) from the app thread and came up with this post on in-app language selection in code. This looks like it was designed to localize text, however, I have a hunch the keyboard language will follow suit. Good Luck!
http://dotnetbyexample.blogspot.com/2011/07/mvvmlight-based-language-selection-for.html
Thread.CurrentThread.CurrentUICulture = new CultureInfo(CurrentLanguage.Locale);
Thread.CurrentThread.CurrentCulture = Thread.CurrentThread.CurrentUICulture;
Obviously a subjective question but I figure this site has built up a multinational audience so hopefully there will be some good insight.
The option I am thinking of going with is a combo box with flag images to indicate which language you want to view your application.
Pros
Everyone recognizes images so you don't have to worry about somebody not being able to select the language of choice because they don't understand what the box is for.
Combo Box supports many (as many as will fit on the page or more if has scrolling capability) using limited screen real estate.
Cons
It may not be obvious to everyone using the application that this is the way to select the language of choice.
The flag chosen to represent the language might offend speakers of that language from another country whose flag was not chosen (Which country's flag do you use for English, Spanish, Portuquese, etc.)
Another option is to use a combo box where each language is represented in its own language so speakers of that language will recognize their language in the drop down.
I am writing this for a desktop application and was curious as to whether a consensus standard has arisen either on the Web or Desktop world that most people "get".
The right answer for me is the control that most user's immediately understand the intended purpose and how to use the control.
My vote: combobox with a list of language name and then dialect in parenthesis.
For example, to list Portuguese:
English (UK)
English (US)
português (Brazil)
português (Portugal)
Language name comes first and alphabetized and written in the native language, that way it will be easiest to find. Name of dialect second so that all the dialects will be together alphbetically, making it easy to see if, for example, there is both UK and US English or just one of them. Little flags sometimes help but sometimes just add clutter.
Another thing: Let the user select language at install time. It must be the first thing that he sees. The Nullsoft installer does this well. Expecting the user to naviagte menus like Tools->Options->Configuration->International->Language in a foreign language is unacceptable!
Never assume that you can glean language from regional settings! Often Windows is configured for the local currency even though the user doesn't speak the language.
Kudos for recognizing that each language should be written in its own language! Often I see a list of languages, all written in some foreign language, and I can't tell which one to pick.
Another option is to use a combo box where each language is represented in its own language so speakers of that language will recognize their language in the drop down.
That's a fairly common practice, and it makes good sense.
Next to the flag, put "Language" and don't localize it. Nearly everyone who is familiar with changing languages in software knows what that means, and having the flag next to it will get the rest :)
This is not an easy problem. The flag idea works fairly well, but I need to train myself to look for the Union Jack. Depending on the application, I might want the Stars and Stripes instead because there is a difference between British English and American. It can get tricky if you try to overload too much meaning onto the flag. For instance, what language is meant by the Swiss flag. Or what if I only speak Spanish, but want the application to use US date and time formats. And don't even think about what will happen if you localize into Chinese. (Example: do you have a Taiwanese flag or not?)
I tend to prefer the languages written out. It gives you a lot of flexibility to specify exactly what language is meant. In addition, you can have a bit of fun sometimes. Facebook has a Pirate English option which is good for a few laughs. Google has even more fun interface language choices. And everyone who needs the Español option will know what it means.
I personally prefer a smart app that makes its best to detect to detect my language. Of course, a languages submenu tight either to a menu item (such Preferences/Language/) or a toolbar button (image is a world icon) must be there somewhere to let user override the automated choice. But in most cases, they shouldn't have to think about it.
Important: The submenu (or combobox, whatever) should contain native language names. That way, users always find their language.
Flags are not such a good idea IMO: Very small flag icons are not very distinctive. Plus it's easier to find a language name rather than a flag. And flags are related to countries, which is not quite the same as language: Some of your English users might not like a US flag that much.
Depending on the technology you use, you might find my codeproject article interesting:
http://www.codeproject.com/KB/locale/LanguageMenu.aspx