I have a French website that is in LFR (Left to Right)
And the client is wanting to translate the site in hebrew thus transforming it to RTL (Right to Left). In all Hebrew Website the design is reversed
https://he.wikipedia.org/wiki/
https://www.google.co.il/
Is there a way to do this automatically ? Again I am not talking about the text direction. I want to flip it horizontally the design, like a mirror effect.
Your mileage may vary. Some web page generation tools support RTL with easy switch, while with others the WYSIWYG breaks completely when you specify <html dir="rtl">. Browser fragmentation may also be an issue: some browser simply don't support RTL bulleted lists correctly.
There are quite a few good tutorials on the Web; I would recommend https://hacks.mozilla.org/2015/09/building-rtl-aware-web-apps-and-websites-part-1/ and https://hacks.mozilla.org/2015/10/building-rtl-aware-web-apps-websites-part-2/. If you look up Google to search for more articles, please remember that this field is quickly changing, and some recipes of few years ago may be obsolete.
You may find the automation with css-flip or rtlcss useful.
Note that localization is generally not easy, and invariably requires a manual touch. You must understand the target culture very well to recognize tiny glitches that may look awful to the end-user. For example, on Hebrew Website you need different image for the "back" button. On Arabic sites, some numbers should be represented by indic digits, but other numbers are expected to use the usual digits.
Issues of first day of week, etc. are common for LTR localizations, too.
Related
Is there a user control (standard or third-party) for iOS that allows to display vertical text of East Asian languages? I also need to display a ruby characters (furigana/reading aid) near the text. Result should look like this http://img23.imageshack.us/img23/3262/img0088xa.jpg (japanese iBooks screenshot)
At this time you will need Core Text or a view using Core Text.
Github search fails but googling in Japanese wins.
http://cocoadays-info.blogspot.jp/2012/01/coretexttextview-lccoretext.html
Blog article in Japanese on this
https://github.com/novi/LTCoreText
Should do the trick.
Too bad github search doesn't find it.
Google translate may or may not help. I've forked it just now and will translate the read me soon.
Also found https://github.com/hokuron/CTRVerticalTextView
Though it seems fairly unfinished and it's owner's blog seems down.
A Japanese site has this nifty page of bookmarks on the topic.
http://b.hatena.ne.jp/Watson/iOS/CoreText/
I have a client who I am pricing an app for, however other than the English version they would also like a Japanese version. Has anyone had experience in a similar case, is there an easy way to do it? Do I need to create two versions, one English and one Japanese? If it were two Latin languages I could imagine it would be easier but Japanese write from top to bottom, right to left so this worries me.
You don't seem to know a lot about Japanese. They're perfectly accustomed to western-style left-right, top-down writing, especially due to the influence of computers. You can of course create separate views (views only, no need for separate apps) for Japanese that switch everything to top-down, right-left writing. But it's only a minority of apps that do that. In fact, the Daijirin Japanese-Japanese dictionary is the only example I know of.
Talk to your client what kind of Japanese localization he wants. Odds are, he just wants strings replaced. See #kelloti's answer.
As a general advise: Make sure you get a native translator/developer who can guide you in a good localization. Don't simply copy-paste in strings you get from somebody else that you have no idea how to even read. This only produces terribly localized versions.
Read the Apple documentation on internationalization. I don't think you should have many issues with Japanese (how else would they sell phones in Japan?)
We've started using TFS at work, and I'm migrating my bugs from the previous issue tracking software to TFS. All of them are written in Hebrew, a right-to-left language, but mixed with English words.
All the text fields in the TFS client are left-to-right, so I have to manually go and press Ctrl-Right-Shift in all the fields in order to read them properly.
Is there any way to change the default text orientation in TFS client?
I looked into customizing the work item form elements, for example here:
http://msdn.microsoft.com/en-us/library/ms194963.aspx
but I couldn't find any attribute for changing the text orientation.
As far as I understand it there is not a way of changing the text orientation in the work item definition. I've passed your question along to some guys on the team in Microsoft to see if they know of anything.
is there an answer? Since then I continued searching for a way to do this, but I couldn't find any.
This is a serious usability issue for me, especially with the titles, which have mixed Hebrew-English. When displaying the issue titles I have to read "backwards". When scanning a lot of issues, this is a serious pain.
And I do not have the spare time to translate 500+ issues from Hebrew to English.
I'm looking for an internal representation format for text, which would support basic formatting (font face, size, weight, indentation, basic tables, also supporting the following features:
Bidirectional input (Hebrew, Arabic, etc.)
Multi-language input (i.e. UTF-8) in same text field
Anchored footnotes (i.e. a superscript number that's a link to that numbered footnote)
I guess TEI or DocBook are rich enough, but here's the snag -- I want these text buffers to be Web-editable, so I need either an edit control that eats TEI or DocBook, or reliable and two-way conversion between one of them and whatever the edit control can eat.
UPDATE: The edit control I'm thinking of is something like TinyMCE, but AFAICT, TinyMCE lacks footnotes, and I'm not sure about its scalability (how about editing 1 or 2 megabytes of text?)
Any pointers much appreciated!
FCKeditor has a great API, supports several programming languages (considering it is javascript this isn't hard to achieve), can be loaded through HTML or instantiated in code; but most of all, allows easy access to the underlying form field, so having a jQuery or prototype ajax buffer shouldn't be terribly difficult to achieve.
The load time is very quick compared to previous versions. I'd give it a whirl.
In my experience a two-way conversion between HTML and XML formats like TEI or DocBook is very hard to make 100% reliable.
You could use Xopus (demo) to have your users directly edit TEI or DocBook XML. Xopus is a commercial browser based XML editor designed specifically for non-technical users. It supports bidi and UTF-8. The WYSIWYG view is rendered using XSLT, so that gives you sufficient control to render footnotes the way you describe.
As TEI and DocBook don't have means to store styling information, those formats will not allow your users to change font face, size and weight. But I think that is a good thing: users should insert headers and emphasis, designers should pick font face and size.
Xopus has a powerful table editor and indentation is handled by nesting sections or lists and XSLT reacting to that.
Unfortunately Xopus 3 will only scale to about 200KB of XML, but we're working on that.
I can't really decide on one of them. IMHO they are all not very good and complete. They all have their advantages and clear disadvantages. If TinyMCE is your favorite then afaik, it also does tables.
This list will probably come in handy: WysiwygEditorComparision.
I've also used FCKEditor and it performed well and was easy to integrate into my project. It's worth checking out.
Small correction to laurens' answer above: As of now (May 2012), Xopus supports UTF8, but not BiDi editing. Right-to-left text is displayed fine if it came from another source, cannot be edited correctly.
Source: I was recently asked to evaluate this, so have been testing it.
I am designing a localized web app. I am leaning on auto-detect browser language setting. But I notice a number of respectable sites asking the user to select a language. Is there any usability issue you know of (from actual experiences out there) with just auto-detecting user language?
Thanks.
Give me a choice
Remember my choice
Use the auto-detect as default
Make transition easy
In many situation I prefer or even need the "original" over my local one, bad translations or different content being the major reason.
If you register multiple domains, you can base your auto-detect on that: When foo.com redirects me to foo.de, or otherwise shows me a german interface, it is actively ignoring my choice to go to foo.com.
MSDN did insist on showing me atrocious automatic translations and ALWAYS made me click to go to the readable, understandable english one (that's a step up: when they introduced it, the default selection for changing the language was something like Afrikaans).
Make transition easy: i.e. make it easy to go to the counterpart of the current page in a different language. Amazon often succeeds when I change ".com" to ".de", but then it fails to lead me to the german translation of the item. That's not always possible, as that requires each local view having the same structure and a 1:1 page mapping. But generally, you have to weight above requirements against other constraints of the project.
[edit] MSDN got better now :)
I would suggest to autodetect the language and display the site in this language or the default languge (probably english) if the translation is not available. Additionally present the user with a selection of languages on top or bottom of your page. The names of the languages should be written in the target language.
Don't do it like that: English, German, Italian.
But: English, Deutsch, Italiano.
Obviously there is the usability problem that you might detect a language that the user doesn't understand. How are you going to do the detection? Don't think everybody has their browser set to the correct language. IP-Adresses are also a very bad indicator for the users language.
Practical example: YouTube tried to convince me for a week or so to use the Japanese version, though I can't read Japanese. Not very helpful. Microsoft is also determined to serve me automatically translated versions of there documentation when I just want to read the English one.
So don't try to tell your users which language they're supposed to prefer, let them decide for themselves.
I really hate non-configurable auto-detection because a lot of applications are translated more than imperfectly. I would rather read perfect English than bad Russian. For example, some terms do not translate in a reasonable way, and trying to translate everything makes localized version faintly ridiculous.
Also some applications can not translate new features fast enough, leading to a mixed language.
So I always prefer to have a choice, and choose the version that is native to the application author -- for the best language (unless it is a language I do not know).
Update:
One situation when it has gone beyond ridiculous is DB2 (or its client tools, not sure), which forced me to install a Russian version, but all errors in this version were shown as "???????? ??? ??? ??".
Yes: at work, we have a Windows XP deployed with 'English' language (because we have worldwide site and only one kind Windows to deploy with only one kind of settings when it comes to language).
Yet all out applications must run in French. The auto-detect feature alone would not be enough for an appropriate display of the labels.
Sometimes when you are trying to describe something to a user over the phone and you are in a different location, it is very annoying when you are both looking at the same URL, but see different results. You might even go so far as to include the language in the URL similar to how wikipedia does it (e.g. en.wikipedia.org).
Also sometimes a user will be on a friend's computer and try to access a website but won't see it in their preferred language, because of the language settings on the computer.
I think the best solution would be to allow the user to override the setting, but default it to the auto-detected language.
I agree that the auto-detect is not enough.
Not many users know the settings for selecting their language. Therefore the settings will often be the default and therefore incorrect (for non-english users).