What if I have a captcha that displays a series of English characters. Will people who don't speak English have trouble interpreting and/or typing these characters? If this is the case then what is the best solution for an internationalized captcha?
Since 99% of the URLs are in regular ASCII, I don't think you will have a problem..after all how would they get to Google or Yahoo if they couldn't type the URL
That said I have on occasion run across Chinese characters used in captchas
Image-based CAPTCHA has two main advantages over text-based CAPTCHA:
International
Harder to solve algorithmically (see PWNtcha - captcha decoder)
There are several flavors, such as:
Classification: see Captcha The Dog, KittenAuth, Microsoft Asirra
3D projection: see 3D images: A human way to create Captchas and 3D-based Captchas become reality
Detection: see Image-Based CAPTCHA from Confident Technologies and Pic-Capture
Rotation: see A Dynamic, User-Friendly Captcha With Pictures
Puzzle: see Key Captcha
It would be a problem for users using their native, non-Latin keyboard layout, for example Russians and Greeks. They would be forced to switch keyboard layout just to fill security question.
Another thing is an ability to even recognize the words - somebody who doesn't speak English could have huge problems with getting word right. Even I sometimes do (for less popular words), although I am quite proficient...
In other words, don't do this mistake, your application should be easy to use for all users.
It's definitely a concern. Dictionary-based CAPTCHAs should ideally adapt to the user's language preferences and ask them to recognize words that match their language preferences and by extension the character set they are most familiar with.
But in the absence of such internationalization, I would say that numerals and mathematical expressions are the most universal solution, and for word-based CAPTCHAs a random series of ASCII characters (which being random would be culture-neutral) would be the most accessible as pretty much any user around the world has the ability to enter these characters even if some have to switch their input method.
Now where it really gets tricky is providing accessibility alternatives for visually impaired users. Making a univeral audio CAPTCHA seems pretty much impossible (you could consider a set of universally-recognized sounds instead of spoken words, but I doubt this would provide sufficient security). And internationalized (multilingual) spoken word generation is far from trivial.
No, because English captchas are ASCII -- ASCII is always available, even if people have a Japanese, Chinese, or Russian keyboard. So this should not be a problem! And image based captchas only require the person to read the letter - and that should be possible for anybody on the web who can see, as SQLMenace pointed out.
The other way around is a problem though.
Google's reCaptcha has a little icon where the user can get a different captcha if for some reason the captcha is not readable or contains foreign characters.
I would recommend that you use Google's reCaptcha, rather than implementing it yourself.
Added Benefit:
Google's reCaptcha is also available for other languages btw. http://www.google.com/recaptcha/faq
which makes it possible for you to internationalize the captcha for the user's default locale.
EDIT:
There is a work-around for Google's reCaptcha to work with flash!
Check here:
http://groups.google.com/group/recaptcha/browse_thread/thread/e22d7e3c91bcc9db
Sure they are a problem. Would a Russian captcha be a problem for you? What about a Chinese one?
The URLs are indeed ASCII, but that is only relevant for geeks.
Regular people go to Google, type some text in their own language, and then click on one of the answers. Then never get to type an URL.
Yes, this could represent a problem to a small percentage of users. Is it a large enough problem to take into consideration when building the UI for your site to better the UX? That's up to you. If it were up to me, probably not.
To help you in the right direction though, I would use Google' reCAPTCHA. It serves a great cause and works like a charm. There's also a great API where you can customize the language that it displays. You could use PHP to detect their country and write some code to change the settings to display in their native language.
Here's a sample of changing reCATCHA's language. "fr" is french!
<script type="text/javascript">
var RecaptchaOptions = {
lang : 'fr',
};
</script>
Google reCATPCHA's API:
http://code.google.com/apis/recaptcha/docs/customization.html#i18n
I believe that the 24 letters that constitute the English alphabet correspond in most 90% of the world. We have Chinese, Japanese, Cyrillic and Arabic users however all of them have the possibility of switching to an English keyboard within their operating systems.
We have no diacritics in English which makes everything a lot easier and our system more easily adaptable all over the world. Everyone types ASCII but they are able to switch to their own zone-specific/language-specific characters.
Related
I'm working on an RTL text document and I'd like to switch the display to RTL. The man page doesn't seem to mention anything regarding direction, only encoding.
P.S. I saw other less related questions here (e.g. this), so I hope it's on topic.
less as such does not do this. While it can work with UTF-8 (see FAQ), RTL/LTR is a step further, and less portable. Actually "BIDI" may yield more possibilities than "RTL". But you have to pick through the possibilities. A web search for
less+pager+bidi
finds something that seems promising: LESS-bidi - Direction agnostic stylesheets, but (for whatever reason) the name LESS is misleading since that only deals with CSS for a browser. It has been dormant for nearly 3 years as well.
The Translate Shell page implies it has a workable viewer for BIDI text.
Ubuntu lists a package bidiv which might be useful.
Have we finally got to the point where we assume CSS2, and hope for CSS3?
(Not looking for discussion, if the answer is "yes, you idiot", go for it...)
You should always take into consideration users who
A. use screen readers and text-only browsers
B. are on mobile devices
C. are not human (i.e. search engine spiders)
By having a good separation of content and style, you should be able to address each of these with ease. As far as users who have CSS disabled, in this day and age, I don't think a designer should concern themselves over it too much. It's certainly not worth spending a significant amount of time and resources on.
What is your target audience and what is your cost for supporting (or not supporting) certain clients?
In addition to the fine points made by pst and ttreat31, I'll add that using semantic markup will generally let your document be readable with CSS disabled (i.e. using the browser's default CSS).
There may be a few quirks (forms come to mind), but generally I find with my own pages, they are plenty readable.
You, and your business, will probably survive if you require CSS. But you'll probably do better if you DON'T require it.
By catering for non-CSS cases, you'll write better markup, with better-structured content. You'll mitigate cross-browser problems, and develop a more robust API. Search engines will be able to parse and 'understand' your content that much better.
Allowing for 'no CSS' is much more about the philosophies relating to web standards and good coding practises than it is actually about the common final rendering.
I don't take any effort to help users who disable CSS or javascript. If I worked on a site which counted on attracting new customers and had lots of first time hits, then I would probably try and give non-javascript users a scaled down set of features. But I would never bother with users who disable CSS. I think that is probably a very small minority.
I often surf in the terminal using links or lynx when my computer is overloaded and I just can't have Firefox, Java, and some Flash applications taking half of my RAM. Text-only browsers don't have advanced CSS or Javascript support.
Many server administrators might do similar thing as most servers are headless, and some administrator might be too lazy to open their other laptop just for a quick browse. People using screenreaders usually have similar view as text-only browser, except it's now read aurally instead of text-only.
When using text browsers, I wouldn't expect any fancies colors or tables, usually I just need to have some quick information. So, IMO, you should at least make all the page's essential information available as plain HTML.
We have a website in brazilian portuguese developed using Coldfusion (for the user interface), Hibernate (for the business logic) and Oracle database.
If we consider to support russian, mandarin and japanese languages what concerns do we must have?
Thanks in advance.
The main consideration is to make sure everything (and I mean everything OS,shell,web server, appserver, database, editors) is configured to use utf-8 or unicode by default.
If you expect a lot of asian users its slightly better to use full unicode as most chinese characters fit into a 16 bit UTF-16, but, can take up 24 or 32 bits in utf-8.
With Coldfusion and Oracle this should not present any mojor problems.
The other main consideration is how you plan to handle the internationalisation isssues.
The standard way is to keep langauge/cultural specific items in a "bundle". There are several tools out there to support this, basically you write your app in portuguese making sure all text the user will see is in quoted literals, then run the app through a utility which replaces all literals with a library call and extracts all strings into a "bundle" file. You can then edit the bundle to add other language versions of the strings. The great advantage of this is that these formats are standard and translation agencies will have the tools to edit these files -- so you can easily outsource the translation to specialists.
The other option which requires much more work but IMHO produces a nicer result is to branch of a version of the front end for each language/culture supported. This gets around a lot of problems with text height and string size. Also it handles cultural norms better -- different cultures have differnet ordering and conventions for things like address and title.
A classic example of small differences causing big problems is the Irish Republic and Post Codes, they just dont have them. So if your form validation insists on a Zip code it will annoy your Irish users. The Brits do have post codes but these are two 1 to 4 character alphanumeric strings separated by a space, not the more usual 5 or 7 digit numeric codes.
Does anyone have some knowledge with internationalization with JavaME? I'm looking for as much information as possible like examples, experiences and maybe some best practices.
Thanks
A few thoughts. J2ME doesnt support i18n as it the api support is not there (cant use resource bundles). But we can do this to a limited extent. Here is what I found out.
It is difficult if not impossible to support english and say chinese languages (typographic characters) for a given J2ME app. But easier to support english and say spanish (I forgot the correct nomenclature to talk about i18n support but you get the idea).
We can have all strings in one config class, that way you can swap this one out for different languages.
We can have the text/strings downloaded from server on initial launch of app and thus have the ability to swap it out from server.
Because of different screen sizes, it is best to work with custom fonts so that code can be written to calculate the text length while displaying it. This will make multiple language support easier.
Image assets can also be downloaded from server based on different languages. But I dont think we can change the midlet icon, so it should be generic.
With this in mind it is possible to design multiple language support.
omemuhammed's answer is an excellent coverages of localization in the mobile space.
I've only had to support EFIGS (English, French, Italian, German, and Spanish). We stored all strings in XML, had an XML pack for each language. We would then compile these XML packs into proprietary binary data and had the ability to build either all 5 languages into a build, have only one language for the build in cases where the application size was tight, or download the binary from a server.
Other considerations with localization is screen layout. I also recommend custom fonts in order to have better control of the display across many different devices. You will need some auto-wrapping code to be able to adjust to different screen resolutions and aspect ratios and you will need a way to handle strings that run off the screen on some devices. Either paging or or scrolling would be a good solution.
Finally, just know that German will screw up your formatting. Try to allow 20-30% padding in English for menus and other UI elements as the German translations will be much longer than the other languages.
See the actual internationalization spec for JavaME: http://www.jcp.org/en/jsr/detail?id=238
Recent Symbian phones should support this.
One obvious advice is to actually try your application on a localized phone: Get a phone from switzerland (it should support at least 4 languages) and another from hong kong (with 3 different version of "chinese"). It might be worth looking into eastern europe/ex-ussr too.
When the actual characters aren't your usual ascii ones, you do need to use a TextBox or TextField in order to have the localized native control on the screen.
Keep in mind that when you use RTL (righ to left) languages, like arabic, you should invert positions of almost everything on the screen, like a list would look like this on latin languages
List item 1
List item 2
List item 3
but the bullets would be on the other side of the screen on arabic (tried make it here, but I could´n generate na inverted list :P )
One other thing is that is better to store your strings in a class than a plain text properties, as this may cause some errors interpreting the unicode of some languages depending on the OS and text editor you are using.
What I usually do is have a I18nManager Class that stores the language in the startApp and through this class I get all the strings I need.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
In a discussion with co-workers today, I lamented that I can't ever remember what an icon means, and have to hover over them to see the tooltips, and thus to find the button I need.
On their side, they were saying that when the text needs to be translated, it might not fit (German vs English for example), and that every place where there is text, including tooltips, it needs a translation. So plain icons are easier.
What is the best tradeoff in useability for the extra work of text vs the subset of users who are icon-challanged?
I personally prefer text and hate icon-only UI's. I know that other people think the other way, equally strongly, either because of internationalization or because their brain works more rapidly with images than with text. If you choose one or the other exclusively for your UI, then part of your user base will be unhappy with your choice. (Sometimes this is the right choice, depending on how extensively the UI will be used.)
Internationalization is really not that difficult, except for finding a firm to do good translations of your text. The programmer portion of internationalization is pretty straightforward. However, I've known a number of programmers who prefer the all-icon method as it's less work. I've personally had to replace one all-icon-no-text UI that the users didn't like. The users said they could not remember what the icons meant.
I think more typically, many advanced users will prefer icons and many beginning users will prefer text. However, a number of advanced users prefer text. IMHO, any good UI will provide tooltips, so you need to translate your interface no matter what you do.
The most friendly solution is to offer both text and icons, possibly with a settings choice to disable one or the other.
I worked with people in a Human/Computer Interactions group and was raked over the coals for using icon-only. They had studies about comprehension, error rate, and speed of using UI's and a good icon/label combination won every time, all else being equal.
Localization should be a non-issue. You may have to localize the icons anyway and localizing a label (as long as it's stored as text and not as bits) is easy. In terms of size in the UI - that's another matter entirely. If you can't fit the text, I'd claim that your UI is too cluttered.
Really they both have advantages and draw backs. Text must always be translated into different langugues, and sometimes a single word will not be able to effectively describe the action of a button. For example, how would you describe the X button which closes a window in Windows. We know what it does, and most people I know call it the X button, but it doesn't describe what it does. It's a lot easier to put a button with an X symbol (or icon if you will) than put something like "close window".
That being said icons also have drawbacks. As you eluded they may not always be clear what they do. The user has to be able to put the icon in a social context to understand what it does. This may not always be possible. Also, icons in one language may not be understood in another, leading back to the translation problem. Icons can be advantageous in certain areas as they can take a complex concept and show the user with a small amount of space. (like to take a picture show a camera, or delete something showing trash can).
The trade off is really in a case by case basis. If you have power users who really understand the application they are using and the surrounding subject, you are probably ok with using them. If you have people who use computers once a month and don't really care to learn it is going to be confusing. Its the amount of information you can convey with a single symbol (icon, picture, letter) vs. the potential frustration of the users and the overall rejection of your program.
Make sure you have a way to get both. Screen readers have a horrible time with icons.
I hate icons, because I never know what they mean even if they're perfectly intuitive (like this world icon that means hyperlink above this box in which I'm typing). Several Unix terminal applications provide a choice between:
text
graphical icons
both
That's nice. I usually like the text on a prominent button, because the meaning of the button is much more clear and the mouse target can be a little bigger.
Its a cultural thing as some symbols (icons) mean different things to people of different cultures, backgrounds and experiences. There are global symbols that one could assume to be 'known' by the general population, i.e. the 'save' icon...
It is a fine line, but i think the tooltips are a good way to help out those who dont understand the meaning of the icon. Perhaps a set of options to have the buttons (icons) render with text instead of the icon image ? This could be a user preference in the application.
Perhaps a good reference would be some of the "extensively" used icons in microsoft applications such as 'Word'. I am generalising here, but microsoft applications are almost eveywhere and they have done all the R&D into suitable / effective icons.
You don't mention if this is for a web application, but if it is then you have to provide the text at least as a backup if the user has disabled images, is using a screen reader, or other limited interface.
two things i guess
the decision should be the result of usability research and properly quantified, rather than a dev's gut feel or whim.
an icon that doesn't carry an obvious meaning is a bad icon and should be changed.
all that said, IMO: Icons with a tooltip/mouseover text equivalent, with bonus that this can carry a reminder of the keyboard shortcut.
(Note: I use "button" here to mean "the UI element on which the icon and/or text is located.")
I think in almost all cases it's important to include text either on the button itself, or at least on a hover-over tooltip on the button, so that in the event that the icon's meaning isn't intuitive to a particular user, the user can find out the meaning by reading the text. (Note that the translation work still needs to be performed in either case.)
A typical case for not including text directly on the button itself is when space is at a premium; when you want to fit a lot of buttons into a small area. Examples include the "toolbars" used in many desktop applications, and also in some web applications -- for example, the buttons that appear just above the StackOverflow answer text entry field!
A good case for including icons is when the button doesn't always appear in the same place, and the user would benefit from being able to quickly visually scan for where the button is located. For example, if I have a lot of programs open on Windows and I want to quickly find my instance of Firefox in the Windows taskbar, I'll look for the little orange icon, rather than reading the text on each taskbar button.