We are currently working with Flex creating a web application. We are having trouble taking Arabic text from the user and displaying correctly (like in a chat feature). While presumably Flash 10 will solve this problem, we don't want to force our users to upgrade.
Flash flips the order of the sentence's words. so if I wrote something like "Hello World" in the text field, it will appear as "World Hello" in the chat area.
Is there a standard way to work with Right to Left languages in Flash?
*We currently flip the order of the words with a function, but it things get messed up when using English or special characters in the chat like :) or :D *
You may also want to check FlarabyAS3Flex here
This would appear to be a Unicode issue, and so a quick talaash via Google gave me Unicode in Flash, but probably more to the point is Flash: RTL (right-to-left), seeing as it mentions Arabic (along with other RTL languages) as well as RTL text output class for Flash.
HTH
you might want to try this:
http://www.red-id.com/blog/category/RTL-Flash.aspx
There is no decent way to support that. Anything you try will be a hack and will break for some cases. And definitely not work for editing.
I would say: ask the users to update.
The penetration of Player 10 is already above 90% in all markets (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html).
And users can understand that you have no choice. It is "update or support for your language is abysmal".
here is an example for handling the text direction in flex.
Related
Suppose you're developing a web site and blind users will be a significant chunk of your target market. If the web site includes document editing functionality, what would be appropriate WYSIWYM tools? Are languages like Markdown, Textile and Wiki Formatting really accessible or are they inconvenient to blind users?
I'm a blind programmer and while I haven't used most of the languages you mention I've found that any markdown language is fairly easy to use if you have the desire to learn it. I've had no problem using either HTML or several markup languages for wiki's. Part of it will depend on how invested the users are in your site. If it's a site that will be visited infrequently or for short periods of time, it's much less likely that a user will take the time to learn the required markup whether they are blind or not. Unfortunately, I have not found an accessible JavaScript WYSIWYG editor but I find it easier to manually enter the markup so haven't looked very hard.
the first question is: how important is semantic structure? could you get away with plain text. You could do simple parsing like treating blank lines as paragraph markers, treating a series of lines which begin with * as a bulleted list, identify URLs and make them into links, etc.
As a blind developer myself, I have no problem in understanding languages like Markdown. But if it's a syntax I'm unfamiliar with, I'll only learn it if I expect to use the site very often, or care deeply about the content.
Two final thoughts come to mind: while I certainly experience some accessibility challenges using TinyMCE, you could develop something much simpler - provide less than 10 formatting options, like inserting hyperlinks, making lists, centering text, setting the style (such as heading) etc.
And lastly, when I talk to non-technical blind people, they often just write their content in Word and paste into a wiki or blog post. This sounded strange when I first heard it, but it does make sense. So an ideal solution would accept pasted in content.
In closing - it depends how important this is, and how much effort you want to expend. Maybe a Markdown editor with a live preview (like on this site), buttons for inserting simple formatting like URLs, and the ability to paste in rich text would tick all boxes :-)
On a web page, the most accessible embedded text editor for blind users is one that uses standard HTML, such as a <textarea> element, with a corresponding <label> element:
<label for="editor">Enter your text here using wiki markup:</label>
<textarea id="editor"></textarea>
If a WYSIWYM tool is built using standard accessible HTML, then blind users can easily enter text into it, with full confidence that they're entering text in the right place. Then the question becomes: Which is the better markup language? They all require memorization, but some may be more intuitive than others. One way to find out which is best would be to do some usability testing with a wide variety of target users. Also be sure to providing easy, accessible access to syntax help.
Picture yourself working in pure text 80x4 display (just open a console and resize appropriately), then use vi/emacs/ed and you'll soon realize what markup will get in the way.
Try to do as much work as possible to understand plain text, else use light markup like POD, finally things like AsciiDoc are very powerful but needs training.
I don't know about WYSIWYG/WYSIWYM tools, but I do know that complying with W3C standards (especially their HTML5 en CSS3 drafts) while writing your own editor code will help a lot.
In CSS you can specify speed and intonation of speech. In HTML you can specify alternative text (alt attribute in many elements) that screen readers are compatible with. Be sure to know when to use the abbr and the acronym elements. Use the former when you want the screen reader to read the meaning of an abbreviation and the latter when the acronym should be read as a word (e.g. ASAP, NATO and OS).
For the editor itself, I recommend creating a WYSIWYG editor that uses divs and spans. Screen readers will understand easily the structure of a document. For the current line, use a text box; for every other line that's not being edited, convert the contents immediately to valid HTML.
If you find a good tool, be sure to post it here. I'm looking for one too. :-)
Since the control emits bizzare non-standard HTML, I'm wondering if it has any practical value.
The control emits font tags!
How are others dealing with it? Do you do some sort of RegEx replace on the text?
Or am I missing something?
Does it have a value? Yes. Is it practical? That depends. How much work are you willing to do to get something useful out of it?
I had to use the RTC to create a chat window for a chat app that was built on Jabber. I wound up having to parse every line of every chat message, check its textwidth, GREP out the bogus HTML (TextFormat and Font tags) while leaving the styling tags (bold, italic, etc.) then shift it onto a queue that would scroll upwards as new messages were sent and received. I had to keep an onscreen buffer of 200 of these lines (taking care not to delete partial messages at the end of the queue). I also had to plot where the emoticons — :) ;) :-) and the like — were located, find out their exact locations, and then draw the emoticon images onto a sync-scrolled Canvas that exactly matched the position of the chat output window. All this while keeping the text selectable and letting people copy and paste it, complete with emoticon tokens that reverted to whatever text smiley upon pasting into the input field.
Was this a lot of work? You bet it was. Was the product ultimately useful? I like to think so. It was pretty cool, in fact. And as it was one of the first Flex projects I ever worked on, it taught me a lot.
Do I wish Adobe supported real, non-gimped HTML? Absolutely.
Short answer: Getting something out of the RTC is a bitch, but probably still faster than doing anything similarly useful in Java or C++. YMMV.
How do you guys handle translation/internationalization of your ASP.NET applications? How do you work with your translators?
We have ASP.NET apps that need to be available in German, French, Italian, English. We use string resources everywhere. However, more than once, our translators have told us just getting a bunch of "txtMyTextbox.Text" and then a German text to be translated is next to impossible to deal with - the context is missing.
So are there any other solutions available? Due to the fact these translators are dispersed all over Europe, we cannot get them to fly in and do their work "on location" - there has to be a way to send them the text fragments to be translated, along with some context, and let them do their work.
Is there any tool out there that would allow me to package up my ASPX pages and ASCX controls along with the text resources, and that would actually visualize them to the translator (without him having to install and host IIS and all) ? I vaguely remember there was a lot one tool in my olden Delphi days that did that - visualize the form (without the real app running), and allowing someone to pick the labels and translate them.
Or would there be a tool that would allow me to make screenshots of my ASPX pages and highlight all label and display their control name ("txtMytextbox") in red, so that the screenshot could serve as an orientation help for someone working on translating a list of labels?
Any hints are most welcome and highly appreciated!
Marc
take a look at the Lingobit http://www.lingobit.com/
How about going around ASP.NET's insternationalization scheme and using a diferent approach, using .po files like the "rest of the world" . The actual text is the key, and translators see that text qhen they are translating. Works pretty well.
http://www.expatsoftware.com/articles/2010/03/fixing-internationalization-in-aspnet.html
describes this.
Make your resource keys more meaningful. This will give them some context
Can the translators get access to a running app? If so, you could set the tooltips of all your labels to be the resource key. That would allow them to mouse over a label to see where its string is coming from.
As your translators become more familiar with the product, they'll be able to better cope with the lack of context. The first time around is a little rough, and you'll need to go through a few rounds of testing and translation revisions. There's not much you can do about it.
Here is the article written by Scott Hanselman. Hope it helps
Globalization, Internationalization and Localization in ASP.NET
I would like to develop a website using ASP.NET in an Arabic language.
What would be some good places to begin?
Useful advice to keep in mind?
I did some of this in a former life, here's what I recall:
Is it going to be just ar-foo? If not (and I would always encourage thinking about the future possibilities), then having a page layout which is either flexible enough to handle RTL and LTR or switchable is going to be a big deal. That includes moving elements like the ubiquitous left-hand menu.
Make sure your character encoding supports arabic and is completely standardised from the DB up. XML/XSLT docs are notorious for being forgotten about here.
It's unlikely but possible that calendars will be a problem. You'll probably get away with using a western calendar in a business application, but the hijri calendar not only varies by country, but in an unpredictable pattern by astronomical event.
Finally, be very very careful with your graphics content. Again, this is unlikely to be a problem, but it's a big one if it does come up. I believe my company at the time actually ran stuff past a cleric at the local mosques community centre.
I work on a collaboration web app, built with Flex 3, that needs to support multiple languages.
Does anyone know which fonts are best for creating embedded font libraries for Chinese, Korean, Japanese, and Russian languages? I know Arial Unicode MS will do the job, but I don't know if it will do the job best.
Localization alone won't solve the entire problem: chat input and display, for example, need to support multiple languages in the same textfield - anything typed in Chinese needs to display in Chinese; anything typed in English needs to display in English.
Using _sans is an option, but is far from preferred.
Thanks.
Went with an approach that switches TextFormat of characters based on unicode value. So, characters in the primary language display in the preferred (embedded) font, while characters in other languages display in _sans.
This works out really nicely, but requires that you inspect every character that is added to a field, and requires you to inspect everything when a deletion occurs. Kind of a lot of inspecting and I'm sure a textfield with a lot of content would start running into performance issues, but this is for a chat tool, so that isn't too critical of a use case.