I'm working on an application which supports 2 languages: dutch & french
If you have your device set in English, talkback reads all texts in the default talkback language
on iOS you have the "accessibilityLanguage" property, but I don't seem to find an equivalent in the android API
Things I've found and tried:
LocaleSpan: works, but I can't imagine it's the goal to wrap every single text manually in a LocaleSpan? I think it's rather meant for texts in a different language then your app language
TextView.textLocale: not sure what it does, didn't see/hear anything different
Is this behaviour of talkback normal? Seems "wrong" to me, but I'm not a TalkBack user myself so I'm not sure, but it's very difficult to listen to the dutch text in an english accent.
Related
Similar to this iOS-question ( VoiceOver announces dimmed instead of disabled for buttons ) I have the same problem, but for Android devices with Talkback.
Why is Talkback announcing some elements like buttons or checkboxes as "dimmed" instead of "disabled"?
Should I somehow change this, or leave it as Talkback reads it? If I should change it to "disabled / dimmed" so that it's consistent over the whole app, how?
[EDIT]:
Example:
It seems that not only buttons use "dimmed", but check / tick boxes as well.
Also only the english language seems to use "dimmed", in german it's still read as "deaktiviert" (disabled).
Don't change it. TalkBack is responding to properties in ways that users would be accustomed to. Sometimes the default behavior is the most accessible because it is expected, even when it isn't quite ideal.
If you would like an answer to the "why" I would need more information on the particular examples that your talking about. Are there apps that exhibit this behavior? TalkBack updated not too long ago, but I generally hear the "disabled" announcement over the "dimmed" announcement from TalkBack from the "obvious" times that such an announcement would apply. I certainly wouldn't expect there to be a general distinction between the two.
Also, I'm looking through the current version of TalkBack (again TalkBack has been updated recently, so the open source version may not be up to date and available) and can't find the localized string "dimmed" anywhere. There are references to "screen dimmed" but this is certainly different from what you're talking about. Which suggests to me that the "dimmed" announcement is coming from changes in the code that I would recommend be UNDONE, so as to allow the "disabled" announcement that TalkBack users would be accustomed to. This sounds to me like something someone coming from an iOS background wanted to duplicate. The behavior in iOS is to announce disabled things as "dimmed". Duplicating this on Android would absolutely be innapropriate. Let TalkBack do its thing!
Providing code examples would be helpful for me to be more sure about all of these things, your question is quite ambiguous. What types of controls? A Button for example may behave different from a Tab in a TabWidget, and this may be intentional. The way your question is worded, any more specific answers than I have given would be speculative.
EDIT:
The different parts of this announcement:
Every Sunday (0): The text of the control
Tick Box: The calculated role of the control. In stock Android this will announce as "CheckBox" (I'm testing on 7.0, with the current GitHub TalkBack). Samsung would be best off to leave this as "Check Box" from stock Android OS, I don't know why they felt the need to change "Check Box" to "Tick Box" just to be different. Doing things just to be different is annoying, there is no objective difference between "Check Box" and "Tick Box" (licensing???).
Not Selected: The current calculated state of the control. In Stock Android this would read out as "Not Checked". Unless the app is overriding this, Samsung would seem to be mucking with this as well. They should stop doing so, but again, out of your control and best left alone. Samsung users will be used to this. Though ultimately I find "Not Selected" to be a little ambiguous in terms of a CheckBox control. "Not Ticked" I think would be better.
Dimmed: Again, another thing that, unless your code is overriding (which I don't think it can in this case for this bit of calculated state). This is the calculated enable/disabled state of the control. In stock Android this would read out as "disabled". Again, leave this alone. Samsung would ALSO be best to leave this alone.
It would definitely appear that Samsung is doing strange things to the Accessibility read outs of calculated components. I'm not sure what version of Android this Samsung flavor is built off of, but I don't believe those read outs have changed. I know CheckBox and Disabled have been the same since 4.2 - 7.0 (probably Android O as well.). These minor changes fracture the Android Accessibility Ecosystem. For these particular elements, Samsung would definitely be best off just to leave them alone. HOWEVER, given that Samsung has made these changes, you are best off NOT fixing this fragmentation. Let Samsung users and Nexus users and Motorola users experience things in the way they are used to and get accustomed to their devices. Allow default behaviors unless overriding them is absolutely necessary. Hearing "disabled" when your expecting "dimmed" is confusing, not to mention a maintenance nightmare should Samsung decide NOT to override this any more or vice versa. When the OS is "calculating" state and doing so reasonably... let it happen!
Android Kitkat:
Can you give me some hints about the following question ?
Display always English keyboard for a specific edit text field:
Question:
• How can I make sure the English language keyboard is always displayed when the user selects a specific Edit Text field in his tablet where the localization is set to Russian or Japanese or other language ? Basically override the Russian keyboard for a specific textfield
By default, all emulators have the Keyboards for English, Japanese IME
and Chinese installed. Since the keyboard that is used by Android OS
is a user's choice, there is no way to force using a specific keyboard
in the app code. If you want to get rid of the unnecessary keyboards
in the emulator completely, see the following post: Click here
As Christoph said
I'm developing a keyboard (IME) for Android. I want it to be useful for people from every country. So, I need to know which symbols should be placed on keyboard based on current locale.
My first idea is to copy computer keyboard layouts. Where can I get the contents of preferred computer keyboard layout for each locale?
Also, I've noticed that phone keyboards usually contains some special symbols which aren't present on computer keyboard. Which symbols are important for phones and why? For example, all keyboards I've met provide a way to type '¿' symbol. But this symbol doesn't make any sense in my locale (russian) and isn't used in english. Is there a reason for placing this symbol on every keyboard?
I own an Asus Transformer (first model) with the US keyboard dock.
However, I'm French, and thus have to interact in French pretty regularly, which does include writing accented letters.
As far as I know, the current workaround for doing that is to basically popup the software keyboard, not very convenient.
One implementation of being able to write accented (and other special letters such as ß) with a traditional QWERTY layout is the one used in Mac OS X. For those who don't know, this is accomplished by pressing alt + a-key-which-usually-makes-a-lot-of-sense (I'm not kidding, they really make sense), that will give you the accent, then the letter which you want to be accented (so alt + e, then e will give you é).
That's the behavior I'd like to implement. However, I don't really find where I'd have to do that.
I looked at the documentation about keyboard devices ( http://source.android.com/tech/input/keyboard-devices.html ) but I don't think that's the right place to do any changes as I don't want to change any keymap or keycodes.
On the other hand, I took a glance at https://github.com/android/platform_frameworks_base/tree/master/core/java/android/inputmethodservice (keyboard.java and keyboardview.java in particular) but I have the impression this is more related to software keyboard.
Does anybody have more clues about this ?
Thanks
I had similar problems with entering Russian characters on TF101. I'm more used to phonetic layout than to standard one.
I was able to modify Android example application SoftKeyboard to accomplish that. You can find code at https://protronika.dyndns.org/websvn/listing.php?repname=FLEXKBD&path=%2F&sc=0 .
Sorry, code is very raw with many things hardcoded. I started that project very recently. So it is in "just works" state.
i have followed tutorial Hello L10 in developer.android official website,but nothing regarding arabic.
what are the steps needed for an android application to be in arabic?
for eg,User can have either a combobox or radio button to choose from english or arabic.(i have done this).
Now if user selects arabic whole application characters should be converted in arabic.
even the keyboard presented should be in arabic?if i have to make custom keyboard for this?or any other way?
i dont have any idea.Any tutorial/demo ?.However i have googled around but not get specific material.
Any suggestion?
Users set their locale at the device level, through the Settings application. If their device supports Arabic -- some devices running Android 2.3 and 3.0 will -- then if your application has Arabic translations of its resources, the Arabic will appear. Also, the user will get an Arabic soft keyboard.
Other than providing Arabic translations for your strings, the rest is up to the user and their device.