Is it possible to customize Recaptcha to display text in English only words?
As recently, I found that text could be displayed in other language like Hebrew.
Here is example:
To be honest it is not possible to type such words for ordinary users having keyboard with Roman alphabet and not many know that image can be redrawn.
AFAIK, via the API you may only customize the interface, not the images.
reCAPTCHA uses scans from the real books, so sometimes, even in latin books there are some non latin characters too.
But there should be no problem here. reCAPTCHA displays always two words: one unknown even for the reCAPTCHA (probably the Hebrew in this case), and the other one, which is really checked.
So the user may misspell the Hebrew, but it's OK when he types the other one (latin) word as expected.
(Only guesses, but I think that's how this thing works).
Have you looked at: http://code.google.com/apis/recaptcha/docs/customization.html#i18n?
That's the API. It talks about setting the translation, but I've never used it, so I'm not 100% sure whether it can do what you want.
Due to where Recaptcha gets its captcha string from (text scanned from books), it could very well be limited to languages that use the Latin alphabet.
I bet that Reviled is the challenge word (the one scanned from the book) and the other is the test word (the one it uses to verify whether or not the person who typed the challenge word is actually typing something legitimate or not).
Related
I think, Unicode says (please correct my if I am wrong), for example, Bangla can only use code points U+0980 to U+09FF. And also, codepoint X will represent letter Y.
Who specify which letter will be placed on what location in the keyboard? Is it also the job of unicode?
For example, Who specify which letter will be placed on what location in keyboard for Bangla? I am asking this because there seems to be a dozen keyboard layouts for bangla unicode Keyboards.
What is the deal here?
There is no unified standard or single standardization body for this. The individual layouts might not be standardized at all, e.g. developed by individual companies for their products, or be standardized by some national standardization body, governmental or non-governmental, for any give language/script.
This can also be seen in the Wikipedia list of some common Bengali keyboard layouts here that you are referring to in your question as well. For each layout the respective organization that developed/standardized them is also given. (Note that the site you linked is not actually Wikipedia, but a third-party interface to it.)
My organisation now has a policy to make all documents accessible, and a long list of guidance how to do so. Most of the requirements are OK. Alt-text is only a small amount of work; sans-serif fonts may not be as nice as Times Roman, but they’re readable; spacing using paragraph formatting rather than carriage returns is good practice anyway.
But then there’s figures. On a paginated document, large figures look great floating with text wrapped around them, but terrible inline, because page breaks often cause huge blank gaps in the page before the inline image. Same goes for tables. But our accessibility guidance insists that only inline images/tables are acceptable for screen readers – and Word’s accessibility checker does as well, though the requirement is missing in Microsoft’s accessibility documentation.
Is there some way to make floating images (and floating tables) accessible, so that popular screen readers will know where to parse them in the context of the document? I'm expecting that the documents will be shared as an exported PDF, but even for screen readers to work with the DOCX file would be sufficient.
It sounds as though this is a 'flaw' (design fault) in Microsoft Word's accessibility checker, which doesn't understand text frames being used for table and image layout. Both #slugolicious and my organization's accessibility trainer confirm that having images and tables floating with no additional text apart from the caption is actually fine for modern screen readers.
My error was assuming that my organization's standards included 'No errors from Microsoft Accessibility Checker'. That is not the case.
I am using the Actions on Google Trivia Game template.
Special characters () are not displaying in the chat window.
In google sheets, I have given in the following format.
Question: How to Add an item to the end of the list
Answer1: append()
Answer2: extend()
In google assistant, it was displaying without parenthesis. How to give questions and answers with parenthesis and other special characters?
This is a good one - it looks like the processor that uses what you entered removes special characters. This does seem odd when you look at the question and the suggestion chips.
However... it makes sense if you think about how people are expected to answer the question. If you run it in "speaker" mode, it won't display the suggestion chips, but users will be expected to verbally give an answer. It is pretty difficult to give an answer with parentheses - so the system automatically removes those from what is expected.
A quick question regarding Angular Forms and Japanese characters. Am using Angular 1.2.17, and modern Chrome web browser on Mac OSX (latest).
Am writing an AngularJS application for Japanese market. Everything works great displaying Kana etc on the HTML pages etc. There are no issues with the web server, or Database etc, UTF8 support is throughout the application.
However, for the AngularJS forms, it does not read the Kanji / Hiragana / Katakana unless the word or sentence starts with latin character. Angular $scope appears to be unable to distinguish the fact that the JP characters have been typed at all unless prefixed with a latin character.
Example:
こにちわ does NOT register when typed into the input field, and hence form validation fails because it will think a required field is empty.
Whereas:
adsfこにちわ does register and the form can be submitted successfully. End to end, the JP characters are handled correctly, and get stored into DB correctly. So Angular / JS is parsing the UTF8 text correctly. The issue is likely something to do with how Angular binds to the data ($scope) when only JP characters are provided. It doesn't handle this properly by default.
Does anyone know of any HTML or Angular configuration etc - required Angular module or params, meta tags etc etc, that would coerce the Form to behave properly. Have not tested, but am pretty certain this issue is not specific to JP characters - it is likely anyone working with a non latin alphabet might have experienced the same behaviour.
Must be missing something obvious here.
Thank you for any help at all!
OK, updating this question very late - actually solved it very shortly after asking.
This turned out to be a timewaster question. Apologies.
But if anyone should come across a similar problem then please check for any REGEX declarations in the Form fields. For instance, a ng-pattern="/^[a-zA-Z]/"
Yes, this will do what it says, and exclude Kanji. Surprisingly it does NOT then put helpful validation error on the form field so from UI perspective it appears that the foreign language characters simply weren't registered.
I run a site where it is important to have good and simple URLs that need to be localized.
Example for the english version:
example.com/car/?type=fiat
Example for the Swedish version:
example.se/bil/?typ=fiat (bil is car in swedish)
And ofcourse I would like to handle all of these URLs from the same codebase. What is the best way to handle this?
Should I set up several controllers (CarController, BilController) or is there a "cleaner" way to handle localized controller names?
BR
Niklas
Don't do that. Ever.
Microsoft, a really big, powerful and resourceful company tried that with Excel. In English versions of Excel, you use IF() in formulas. In the German version, it's WENN(). In French, it's QUAND(), I think. In Japan, it's probably ば(). Now imagine someone from Japan sends me an Excel sheet ... There are two options:
"I'm sorry, I can't open this file"
Translate all names on the fly
Doing #2 seems simple enough ... until you run into a word which uses the same letters but has a different meaning in two languages. Example "see". Means "look" in English and "lake" in German. Since you don't know all the languages in the world, you have no chance to figure out which collisions you will have before it is too late.
Also, how do you know which name to use? From the language in the browser? Or do you hate your international customers who occasionally use the Swedish main site? How do you handle Asian languages? Will the URL be server/%E6%AC%80%E6/?%AD%81%E6%AB=fiat?
Don't. Do. That. Ever.
What about rewriting the URL depending on the domain? This way, the Zend framework will get only the English names, while the URL can use localized names.