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.
Related
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.
I am using Protege 4.3 to create and organize an Ontology which contains Chinese characters.
As you can see, some Chinese characters are displayed properly, but others are displayed in little squares. The little squares do not always occur, for example: if I click on the []-[]-[]-cheatsheet-[]-[]-[]-[]-[], I can the same Chinese characters are displayed without problem.
Do you know what I can do to make Protege 4.3 display chinese characters correctly and consistently?
I guess I could have done further homework for this question. It's a post close to the final solution. (I have to post this as an answer for the length doesn't fit comment box)
To be specific, I found from Protege Mailing List Archive the following feedback post
[p4-feedback] Protege 4.2.0 Chinese Display Problem:
https://mailman.stanford.edu/pipermail/p4-feedback/2012-June/004721.html
I know this problem and have even fixed it on one occasion. But I don't truly understand it or know what to do about it. I am sorry that I don't have good information on this problem but I will give you my best current understanding.
In my experience, when this happens the character information is correctly encoded in the OWL file. The problem is exclusively a display problem. This is consistent with your description of the problem - in some of the screens the individuals are displaying correctly.
I believe that the problem has to do with the configuration of fonts in the java virtual machine. If you change the instance of java that Protege is using the problem will manifest in different ways or it will go away. When I worked on this problem before (it has happened
a couple of times) I gathered some web pages. Unfortunately only one of them is still valid, but perhaps it is part of the solution.
I will post my own investigation results after trying the suggested approach above.
PS: A useful owl example is provided here - some unicode characters do not display correctly in Protege
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 don't know if my approach to this is fundamentally wrong, but I'm struggling to get my head around a (seemingly trivial?!) localisation issue.
I want to display the title of a 'System' UITabBarItem (More, Favorites, Featured, etc...) in a navigation bar. But where do I get the string from? The strings file of the MainWindow.nib doesn't contain the string (I didn't expect it to) and reading the title of the TabBarItem returns nil, which is what stumped me.
I've been told, there's no way to achieve it and I'll just have to add my own localised string for the terms in question. But I simply don't (want to) believe that!! That's maybe easy enough in some languages, but looking up, say, "More" in already presents me with more than one possible word in some languages. I'm not happy about simply sending these words for translation either, because it still depends on the translator knowing exactly which term Apple uses. So am I missing something simple here? What do other people do?
Obviously, setting the system language on my test device and simply looking to see what titles the Tab Items have is another 'obvious' possibility. But I really have a problem with half baked workarounds like that. That'll work for most languages, but I'm really gonna have fun when it comes to Russian or Japanese.
I'm convinced there must be a more reliable way to do this. Surely there must be a .strings file somewhere in the SDK that has these strings defined?
Thanks in advance...
Rich
The simple and unfortunate answer is that aside from a very few standard elements (e.g. a Back button), you need to localize all strings yourself. Yes, UIKit has its own Localization.strings file but obviously that's outside of your app sandbox so you don't have access to it.
I filed a bug with Apple years ago about providing OS-level localization for common button titles, tab item labels, etc. That bug is still open but obviously they haven't done it yet (sorry, I don't have the radar # handy).
What's the best way to set up help (specifically HTML Help) for a Delphi application? I can see several options, all of which has disadvantages. Specifically:
I could set HelpContext in the forms designer wherever appropriate, but then I'm stuck having to track numbers instead of symbolic constants.
I could set HelpContext programmatically. Then I can use symbolic constants, but I'd have more code to keep up with, and I couldn't easily check the text DFMs to see which forms still need help.
I could set HelpKeyword, but since that does a keyword lookup (like Application.HelpKeyword) rather than a topic jump (like Application.HelpJump), I'd have to make sure that each of my help pages has a unique, non-changing, top-level keyword; this seems like extra work. (And there are HelpKeyword-related VCL bugs like this and this.)
I could set HelpKeyword, set an Application.OnHelp handler to convert HelpKeyword requests to HelpJump requests so that I can assign help by topic ID instead of keyword lookup, and add code such as my own help viewer (based on HelpScribble's code) that fixes the VCL bugs and lets HelpJump work with anchors. By this point, though, I feel like I'm working against the VCL rather than with it.
Which approach did you choose for your app?
When I first started researching how to do this several years ago, I first got the "All About help files in Borland Delphi" tutorial from: http://www.ec-software.com/support_tutorials.html
In that document, the section "Preparing a help file for context sensitive help" (which in my version of the document starts on page 28). It describes a nice numbering scheme you can use to organize your numbers into sections, e.g. Starting with 100000 for your main form and continuing with 101000 or 110000 for each secondary form, etc.
But then I wanted to use descriptive string IDs instead of numbers for my Help topics. I started using THelpRouter, which is part of EC Software's free Help Suite at: http://www.ec-software.com/downloads_delphi.html
But then I settled on a Help tool that supported string ID's directly for topics (I use Dr. Explain: http://www.drexplain.com/) so now I simply use HelpJump, e.g.:
Application.HelpJump('UGQuickStart');
I hope that helps.
We use symbolic constants. Yes, it is a bit more work, but it pays off. Especially because some of our dialogs are dynamically built and sometimes require different help IDs.
I create the help file, which gets the help topic ID, and then go around the forms and set their HelpContext values to them. Since the level of maintenance needed is very low - the form is unlikely to change help file context unless something major happens - this works just fine.
We use Help&Manual - its a wonderful tool, outputting almost any format of stuff you could want, doc, rtf, html, pdf - all from the same source. It will even read in (or paste from rtf (eg MSWord). It uses topic ID's (strings) which I just keep a list of and I manually put each one into a form (or class) as it suits me. Sounds difficult but trust me you'll spend far longer hating the wrong authouring tool. I spent years finding it!
Brian