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;
Related
Pretty much what the title says.
I have a page with an Entry view in it in my Xamarin.Forms app.
Clicking it brings up the software keyboard which, under all text based keyboard settings(such as url, email, text, etc.), has the option to change the input language.
My problem is that my backend accepts English only, and that's the way I want it as well, but I just can't find a way to disable the language choice on the keyboard.
Does anyone know?
I'm using Xamarin.Forms, and the above description relates to usage on an Android device, I'm yet to test on iOS.
I'm hoping for a cross platform solution that I can use in the PCL, but a solution using custom renderers is acceptable too if no XForms solution exists.
Thanks!
You can do something else to enable only english characters - you can hook to the text changed event of the entry and check inside if the text is english or not.
You can do something like this:
private void MyEntry_TextChanged(object sender, TextChangedEventArgs e)
{
var newText = ((Entry)sender).Text;
// Check for english characters.
...
// If not english, put the old value
((Entry)sender).Text = e.OldTextValue;
}
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?
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.
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
We have an enterprise web application where every bit of text in the system is localised to the user's browser's culture setting.
So far we have only supported English, American (similar but mis-spelt ;-) and French (for the Canadian Gov't - app in English or French depending on user preference). During development we also had some European languages in mind like Dutch and German that tend to concatenate words into very long ones.
We're currently investigating support for eastern languages: Chinese, Japanese, and so on. I understand that these use phonetic input converted to written characters. How does that work on the web? Do the same events fire while inputs and textareas are being edited (we're quite Ajax heavy).
What conventions do users of these top-down languages expect online?
What effect does their dual-input (phonetic typing + conversion) have on web controls?
With RTL languages like Arabic do users expect the entire interface to be mirrored? For instance should things like OK/Cancel buttons be swapped and on the left?
As an Arabic speaker, when I do look at Arabic websites, I do expect things like OK/Cancel to be swapped.
When reading Arabic, my eyes read from right to left. So, in situations where you'd want to reader to view an affirmative/action button (e.g. OK, Submit, Yes, etc.) before a negative/inaction button (Cancel, Clear, No, etc.), you'd probably want to put the former on the right.
Caveat: As weird as it sounds, the above only applies (to me personally) when the button text is in Arabic. If the button text is in English (in a mixed-language web page), I'd prefer to see the OK button on the left.
Hope that helps.
Read Globalization Step-by-Step by Microsoft.
I can answer the specifics on CJKV, but you probably want a book on this topic. I haven't read it but CJKV Information Processing is from O'Reilly (2nd ed due Dec, 2008).
I understand that these use phonetic input converted to written characters.
How does that work on the web?
The input is done by a class of software called an IME (Input Method Editor) on Windows, Mac, and Linux (e.g. SCIM). When an IME is turned on, the input from the keyboard first goes to the IME, and the user gets to pick the correct kanji/hiragana combo. When the user commits by hitting return key, the IME types in the kanji/hiragana into the web browser using the current encoding. Encoding situation was a big mess, but if you are writing a web app, go with an encoding of Unicode. I suggest UTF-8.
Do the same events fire while inputs and textareas are being edited?
A Unicode savvy web browser and OS combo handles multiple languages. For example, one can use English normal version of Firefox to browse and post to a Japanese website. From the browsers point of view, it's just an array of "bla bla bla" in Unicode. In other words, if the event fires up in English, the same event should fire up in CJKV if you use a Unicode variant.
What conventions do users of these top-down languages expect online?
CJKV readers expect left-to-right online. Math and science textbooks are written from left-to-right. Most word processors, including localized version of Word, write left-to-right.
What effect does their dual-input (phonetic typing + conversion) have on web controls?
For the most part you should not have to worry about it, unless you are trapping keyboard events. For example, I hate using Japanese keyboard with bunch of extra keyboard. So, when I have to assign IME on/off command to some key on US keyboard. I personally use right-Alt. Also, spacebar and enter key is used during conversion, but not sure if these events are passed to browser.
The directionality question is easy to answer for East Asian languages: websites are left-to-right, top-to-bottom as per usual.
In fact, the general web design layout principles much the same. Have a look at the websites of a newspaper (name top left, navigation bar under with "Home" on the left, headline links below with most important at the top) or a search engine (don't think I need to say which US site you should compare that layout to).
However, just as Arabic/Hebrew/etc right-to-left language users will expect left-to-right progression in some contexts (embedded English fragments and so on), there are situations, even on the web, where top-to-bottom layout is preferred. This is generally done by including an image with the text layout and font desired, or using flash.
Internet Explorer has actually offered tb-rl layout with the CSS writing-mode property since version 5.5 however none of the other browsers have bothered implementing it (or ruby, which is useful for sites aimed at a young audience). IE 5.5 was released in 2000, so that's eight years of support, and there was a W3C candidate recommendation in 2003 but text layout in CSS still being poked around.
As for your worries with text input and IMEs, as long as you're not doing something bogus like trying to manually translate the virtual keys given by keydown events into text strings, you're unlikely to run into problems.
There are some additional issues you've not mentioned however. The minimum comfortably readable font size is larger than for languages written with the Latin script. Bold and italic for emphasis in flow are generally not appropriate. Han unification means to need to be picky about specifying the right fonts for the different CJK languages when working with unicode. You may want to provide both traditional and simplified interfaces for Chinese, depending on what audience you are expecting.
I've been meaning to write up a more comprehensive guide along these lines for a while, if you need more information feel free to kick me.