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.
Related
Im implementing a language plugin on a site, you know the sort click and it changes all the content into Arabic, Russian.. ect (im aware that modern browsers have built in features for this, but we've chosen to go this way.)
What i was wandering is how we deal with fonts, if our normal site is running using
font-family: "Century Gothic", CenturyGothic, AppleGothic, sans-serif;
Would it just fall back to the browser defaults if it couldn't render the new text in the above fonts?
Or is there a way of specifying fonts after the translation has taken place?
When characters on a page cannot be found in the font listed first in the applicable font-family list, then browsers are expected to scan the list further and eventually, when needed, fall back to scanning other fonts in the system, in browser-dependent manner. However, browsers (especially IE) are known to fail here and, moreover, the process may result in a mix fonts, even characters from different fonts in a single word.
Thus, you should make a reasonable effort to ensure that any font listed in your font-family list is as such sufficient for the text of the page, at least for letters (special symbols may often be picked up from different fonts without stylistic mess). This is virtually impossible for a widget that translates into “any” language.
I suppose you are referring to the use of a service like Google Website Translator. In addition to producing generally bad translations for business purposes, it may mess up the markup of the page, possibly affecting font issues too. For example, it seems to insert rather pointless font markup which may prevent your font settings from working. Moreover, it does not properly set the lang attribute in the translation result (but leaves the original lang attribute!), so you cannot even expect browsers to use their language-specific defaults for fonts right.
I'm not sure what do you refer to when you say "im aware that modern browsers have built in features for this, but we've chosen to go this way" - browsers don't really provide language selection.
There is, however, a reusable JavaScript library that my team developed, that does this, and it takes care of fonts, too:
https://github.com/wikimedia/jquery.uls
https://github.com/wikimedia/jquery.webfonts
You can use it, or take ideas from it to your implementation.
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. :-)
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
Is there any reporting tool which offers multilingual support (namely English en-US and Arabic ar-KW) and support for Web report viewing in IE6 and above. I don't want to end up making different reports for each added language. Development platform for this is ASP.NET 3.5, Crystal Reports or any compatible reporting tool, SQL Server 2000/2005, IIS 6/7.
One way I figured out works if we are only working with the static data then we can add and replace the translations of static text (labels, headers etc) using reports formulas. I'm not sure whether it works with older reports versions but I've tested and it did worked with CR 9 and above. But this is off no use when we need to change the positioning and ordering of the reports columns as well for right-to-left and left-to-right layout languages like English and Arabic...
What is the recommended and best known/developed way to deal with this?
Any bright idea and help would be appreciated.
Please try http://www.stimulsoft.com/
This has all you can dream of and even more !!!!
I mean it !
(It has localization inbuild in the reports so you don't have to make multiple reports etc,just change cultures etc if you know .net culture classes etc)
(There is a version that works on web)
You can use i-net Clear Reports (used to be i-net Crystal-Clear). It support translations of your reports with resource bundles. It support also mirroring of Arabic reports.
Our ActiveReports Product supports multiple languages in the scenario you describe. Being the number one selling report writer in Japan for many years now has also allowed us make big investments in international support for complex languages like Japanese and Chinese that others tend not to such as special handling for exporting Japanese or Chinese characters (and other languages) to PDF.
Scott Willeke
GrapeCity
Izenda AdHoc Reports
provides wide opportunities for multilingual support.
You could change static text(labels etc.) as well as testxs from the database on-the-fly. Really on-the-fly, i.e. change language in one click.
Izenda AdHoc supports right-to-left languages "from the box" and also there is Arabic language pack already. If you need another dialect you could contact support and they will tell you how to get it.
And another great thing is you can easily change any translation you'd like by just editing simple XML file.
I have a requirement to be able to provide a flex component in English and several asian languages. I have looked at the flex documentation and it seems that I have to build several swf's, which feels wrong.
Does anyone know of a straightforward and practical way of bundling string resources in different languages and handling the fonts?
I guess you know the basics of how to localize a Flex application, but if you would like to know more there's a good and thorough description here: Runtime Localization.
In Flex 3 you have three options on how to solve your problem:
compile all languages into the SWF and switch language at runtime
compile a separate SWF for each language
compile no, or a default, language into the SWF and load additional languages at runtime
The first option is probably the most common, the least complex and doesn't have many drawbacks. The other two can be used if you have special needs, like having to keep down the size of the SWF at all cost, or need to load all strings from a database at runtime.
To implement the first option you create a resource bundle for each language (basically a number of .properties files that lives in a directory named after the locale, for example en_US for US English or sv_SE for Swedish). In the code you refer to strings by calling the resource manager:
<Label text="{resourceManager.getString('mybundle', 'mystring")'}/>
That will retrieve a string called "mystring" in the resource bundle compiled from "mybundle.properties" in the current locale.
To make sure each locale is actually compiled into the application you add -locale=en_US,sv_SE to the compiler flags (but change the en_US,sv_SE part to the languages you have resource bundles for). You also need to add the location of the directories to the source path: -source-path+=locale/{locale} (the "{locale}" part will automatically be replaced by the values of the -locale flag).
Now you have compiled all your languages into the SWF and can change languages at runtime. The way to do that is to modify the localeChain property of the resource manager:
resourceManager.localeChain = ["sv_SE", "en_US"];
With the settings shown above the resource manager will first look in the Swedish resource bundle, and secondly in the one for US English. You can set another order at any time, and doing so will change all texts in the application then and there.
I encourage you to read the description I referred to above, it explains this in greater detail, and most likely in a more understandable way. It also explains how to do some preparations you need to do before you can compile applications with locales other than en_US.
The other problem you have is with fonts. That one is trickier. The best thing would be to have a font that had the full Unicode range of characters, that way you would only need to embed that and any text could be displayed. However, that means that your options are a bit more limited. I know that there is at least one version of Aria in Windows that has an enourmous number of characters, and on the Mac there is a Helvetica (I think, or it might be Lucida Grande, or both) that also has most of the ones you need to display many asian languages.
Embedding all languages into the same SWF usually does very little to increase the file size, because text is very lightweight, but fonts are definitely not. Embedding a the whole Unicode version of Arial can increase the file size of a SWF by several megabyte, which kind of sucks for web applications. Depending on the situation you may have to compile one SWF per language, just because the font data would otherwise make the SWF unwieldy.
Beware of fonts. System fonts aren't the prettiest but Asian fonts are too large to embed. We resorted to embedding Latin fonts for English and switching to system fonts for Chinese.
Be careful about rotating system fonts - your text will disappear. I think Flash 10 might have fixed this.
Also, be very careful with the font string you specify for Chinese.
Most OSes have nifty fall-back logic - if you specify Trebuchet and try to render a Chinese character, your OS might decide to use some Asian font instead. Flash seems to mess up this fall-back logic and switch between two or more Asian fonts dynamically. We had cases where mousing over a text block would switch the font.
To fix this, specify a font which includes all the characters you need (without falling back to some other font). You will need to test this across OSes, etc.
We use Flex for the client part of our application and support I18N via ResourceBundles.
In Flex 2.01 the language has to be built into the SWF - you can't change it at runtime. In Flex 3 you can switch language at runtime.
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Runtime_Localization
An important step left out above is to run the command:
copylocale.exe en_US sv_SE
from the bin folder of the sdk. This is in the article though.