I looked through MSDN and couldn't find a clear cut answer to this one. So, if i'm building a localized WP7-application, should i conform to phone's language/culture settings or can i roll my own language/culture-switching mechanism inside the app?
Here's the relevant section from MSDN: http://msdn.microsoft.com/en-us/library/ff637522(v=vs.92).aspx
This is stated in "Testing Your Application":
When changing a display language, verify that the language of your
application UI automatically updates to that language.
Should this be taken as a "soft" guideline or a precondition for Marketplace acceptance?
ps. I know that this question is pretty academic in nature, because i cannot think of any scenario where standard localization mechanism wouldn't be enough.
Edit:
To clarify my point: If i build a localized/globalized app, am i required to or should i use the phone's settings or can i implement my own culture switching?
You would have to perform this sort of test on a real device, by navigating to settings > region + language. In this page you can change language and other locale information such as date format.
I'm not sure, but I guess a developer may implement "own" language switching mechanism inside the app. One example is: I have English choosen as a device language but Czech as region I live. I don't want to see whole OS in Czech but I would like to see one specific application (which supports Czech) in Czech language. It means, without switching OS to Czech this cannot be provided. For this scenario, I think, is the best to have a possibility to choose the language in the app as well - so I can stay in English OS language and I can switch this app to Czech.
Related
I'm wondering if there is any way to handle i18n while building HTML/Js apps using trigger.io (forge).
By the way, there is also no way to detect user's locale on devices, workarounding by inspecting User Agent ( or in my case - a FB connect app - asking FB to get the user's locale)
Internationalization is a must have for any serious app ...
I'm currently "hacking" this by creating several JSON files (one per locale), holding same keys in the appropriate language.
1: Is there any plan of detecting/getting user's locale with forge Js API ?
2: Is there any plan to handle automated i18n while building apps ?
Tks.
You could easily write a Trigger.io plugin to detect the device language for you. Here are some resources on how to do this:
Android: http://developer.android.com/reference/java/util/Locale.html
iOS: Getting current device language in iOS?
As soon as you have the language string you could then use one of many js plugins that handle localization for you OR do it on your own. Having multiple json files with the localized strings and loading one of them on demand doesn't sound too hacky to me.
PS: Of course, if you plan to have a mobile browser version of your app you cannot rely on native plugins. In this case you'd have to use a different solution. Take a look at JavaScript for detecting browser language preference.
There are two things to translate: your JS/HTML app and the native elements.
JS/HTML
Use window.navigator.language to get the locale.
Use some library, e.g. https://github.com/wikimedia/jquery.i18n
Native
The native elements aren't shown that often, but do contain some crucial things, such as permissions dialogs ('The app wants access to your photos').
There is currently no support in trigger.io for translating this section that I know of, i.e. they will all be in english.
But as I understand it trigger.io could add support for this fairly easily, by just making it possible to 'switch' on more languages in config.json, since there are already translations for these dialogs built into iOS, just a matter of 'flagging' an app as having support for the language.
Again, I'm not 100% sure on the native part, but this is how I think it works.
I am creating an application, and I noticed that nowhere can i find text such as 'pin to start' to use for livetiles in my application (creating a secondary tile). I tried to send Microsoft's AppHub a support ticket, but I only received a response saying that I could not be helped with translations? I clearly stated the need to be standardized and uniform across my third party apps and default behavior, but this had no effect on the answer. My problem arises when I translate my applications using a resx translator tool and Bing for my translation service. Some words to not translate correctly, which is fine because I go back through to check and then attempt to do this manually, but phrases such as 'pin to start' which are so unique to the WP7 application list sometimes do not translate properly at all. I would like to be as close to Microsoft's default language translations as possible for supported display languages, but are there any resources which may help me out? Or am I left in the dust to try to figure these out myself?
There is a page Microsoft Terminology Collection where you can download sets of standard texts.
There is no document that will show you the localized versions of the system strings. For that, you will have to dig through OS files, and that implies that you will have access to the WP OS image. You have to rely on your own translation skills or simply switch languages on the phone to check specific strings.
I'm developing a WinForm app in c# 4.0 and would like other (non-developer) colleagues to contribute writing a context sensitive end-user helpfile. First I thought I could use "HTML Help Workshop" from Microsoft, but it seems outdated (Vista and Windows 7 not supported).
Then I've looked at Sandcastle, but the documentation is lacking and I wonder if it is suitable for non-technical users to write end-user documentation.
So I read about RoboHelp, but it's way to expensive for me.
I'm getting lost in all the information that is available about helpfiles. Can someone help give some best practices or information on what tools to use and what output format I should target (still chm or other).
Great question. I like your idea of non-developers contributing to the end-user documentation.
This idea might motivate users and testers of your application to easily contribute to the documentation.
The first thing that comes to my mind, is using a some sort of wiki engine. You could build a simple function in your WinForm application, that fires up a browser and directs in to the wiki. You could use the context from which it is called to build up an url; e.g. http://dev-wiki.mycompany.com/LoginForm?action=edit. Here the name of the form ("LoginForm") is used in the url of a wiki page.
Alternatively, you could simply use the embedded web browser control for WinForms to access the wiki. That would look something like:
var url = GetWikiUrl(myForm);
browserControl.Navigate(url);
This would be very easy to embed in your application.
In a controlled (office) environment, this would be very easy to set up. In you production environment it might be a bit more difficult, but still doable. It might leverage some end-user contributions too.
For writing documentation, I use sphinx.
It lets you document in plain text and has various output formats (chm, html, pdf etc.).
Some of these (chm, html) can be used as context-sensitive help sources.
However simple, the sphinx user-interface (text editor and make file) might not be suitable for non-technical users.
I would recommend to use Help+Manual for creating CHM documentation. It's similar to MS Word and any PC user can start to contribute doc development after short education.
But this tool isn't free :(
I am about to start developing a desktop application, and I am interested in making the application both usable and accessible for end users. Can anyone suggest online resources that offer guidance for developing usable desktop applications? In particular, I would be interested in learning about how to test desktop applications for usability. I am aware of several tools to validate HTML for accessibility; how could you test a desktop application for accessibility?
Thanks, MagicAndi.
I read through the entire Introduction to Apple Human Interface Guidelines, and it was not to my loss. Rumor has it that similar guidelines for MS Windows and Gnome are excellent, too, but I haven't read those.
Wikipedia has interesting pointers to usability. The single best (short) piece of literature I've seen on usability is "Don't make me think" by Steven Krug, with a focus on Web Usability.
As for Accessibility, I haven't read through all of it, but from small exerpts I blieve that real experts have written WIA-ARIA, the W3C take on accessibility.
I forgot where, but these are hints I've learned on how to test for accessibility:
Buy a screenreader and try to use your app with that
Put on glasses that are not yours (or take yours off) and find your way through the app
Try to handle the your App with an imprecise substitute for a mouse, to simulate disabilities of the hand. E.g., try using your app with a trackball, or with a mouse on a reflecting surface.
Turn the sound very silent or off
Use your app with one hand only.
Set your screen to black and white (to check that contrast suffices)
That's all I can come up with now.
I can answer from a MS centric point of view, although some of the tools mentioned should work for other languages that run under Windows.
First there are two open source options on CodePlex that you can run against your applications to verify that you have the building blocks in place for accessibility AccChecker and UI Automation Verify.
You should also use a screen reader to verify your accessibility, in my experience a good one that works with Windows and WPF applications is NVDA Screen Reader.
For measuring luminosity ratios of UI elements I like Colour Contrast Analyzer v 2.2
Microsoft also provides guidance with their Accessibility Labs and Sarah Ford has a really good article providing a great overview of accessibility testing http://msdn.microsoft.com/en-us/library/ms971307.aspx
There is not official standard dealing with the layout of about boxes, which display the credits of a computer software and other information.
What should a good about box contain? And... is it okay to put an easter egg in?
(source: seasip.info)
I generally prefer to make tabbed "About" boxes. The first tab usually displays information about the application (name, version, copyright, etc.). The other tab is usually a log of changes with the most recent changes at the top.
Legal will want their copyright and stuff, marketing will want their branding (even though the user has already bought the product), the dev team will want their names up there in liquid crystal, but what do users need?
App name and version number. Users may need this to troubleshoot problems, perhaps while in contact with tech support or when using a knowledge base. Use a version number system such that this is all the user needs to specify their build. Version number is also needed for the users to know if they can upgrade.
A brief statement of what the app does (e.g., “Photograph and picture organizer.”). Users often end up with software for which they can’t guess the purpose. “About” is a logical place to tell the user what the app is about.
Put the above in conspicuous text at the top of About. Have a single OK button. Everything else that may be required by others in your company really isn’t of any interest to the user and can all be in “fine print.”
You could also include the web site or email for tech support if you can rely on that being stable for years, but usually users have this before going to the About box.
Easter eggs are fine if you think it’s appropriate to have a little fun in your app and your users lean towards the geeky side of things. Just make sure it isn’t something that will alarm a low-end user (or a future high-end developer; see: http://blogs.msdn.com/jensenh/archive/2005/10/20/483041.aspx).
Looking at a few examples of About boxes:
Name of the software
Name of the publisher/author
Copyright and licensing information
Version information
A nice logo
These days, it probably wouldn't hurt to have a way to directly go to the website for the software in the About box itself.
Microsoft's Windows Vista User Experience Guidelines tend to have useful information on designing good user interfaces. I wasn't able to find information specific to About boxes, but the section for Dialog Boxes may be somewhat relevant.
A team in my workplace actually has made the coolest About box ever:
Every time you open it, it displays a different simple game, with pictures of the dev. team (memory games, tic-tac-toe, sudoku, etc)
As for the About page content, that is the best place to have the version / release information so you can offer easy support.
I am using mine as the abstract description and a link to the legal pages and a credits page. If you have a website, its URL should be there as well -- might as well make that click-able into your own web-view browser to your big "Company About" page on your web server (don't launch a real browser, or the user just left your application).
Make it enjoyable to read but be concise. Avoid any scrolling or paging -- except to a completely different set of informational screens.
Also, let it be obvious and easy to dismiss.
By-the-way, if you add an easter egg to an app that is submitted to Apple Store, you have to disclose the sequence for Apple to 'test'; they promise to keep the sequence confidential. If they discover it later, which will make it back to them through forums, etc., then they will automatically pull it from the store.
I tend to add program name, version, company copyright, contact information, license information. I also add various variables for problem resolving. Winows version, servicepack, dll version if i use critical dll's etc. A large application icon. Sometimes I add an easter egg or some keycombo that launch parts of the program meant for debug and support purposes.