I'm just getting started using Resharper with VS-2008, and one of the 'errors' it gave me was to localize a Label's text in the code-behind. I've worked with Localization before to Localize a website from english into french, but I don't understand what the benefit is to localizing beside that usage.
If it's an internal application that you're not going to be distributing, there's not much of a benefit to it. It may be handy to collect all your strings in one central location for easy maintenance later, but only you know whether that's worth the effort on your specific project.
That's a bit like asking what the benefit of addition is beyond adding two numbers together.
Localization is generally about presenting the most relevant user experience to each user with minimal code changes - giving each user a "skin" using their language and regional settings (e.g. for things like formatting numbers appropriately).
Granted very many web sites aren't localized at all, but R# is prompting you do give your users the best possible experience :)
Related
I want to have a group in Plone that can only translate for 1 specific language. Is this possible? And if yes, how?
Use case is that there are quite a bit of languages in a site, and that the translators can only translate for their language.
Not without very substantial customization. With some code added, you could make the translate drop-down actions smarter, so that they only offered particular languages to users from particular groups. That might give you what you need.
If you need security to match, it would be harder. You'd have to intervene (via code) after translation creation to set sharing.
So, possible yes. Practical, probably not.
If this is a very high priority project, and you have resources available, get in touch with the folks working on the next generation of LinguaPlone, and offer to help develop (or to fund development) for the feature. That might be the very best way to make it happen.
Actually — this doesn't have to be so hard.
By granting the translator add and edit permissions in the required language subfolder, and not in the other language subtrees, this should all simply work.
The only real need for customisation might be to hide the translate actions from the menu if the user doesn't have permissions to translate to there.
I have an Administrator that needs a dynamic form generator with layout capabilities on an ASP.NET page so that they can add, edit and change layout of questions that will be filled out by users whose responses will be saved into the database dynamically. The format is very important as there will be an offline piece that will be generated using Adobe Acrobat and both forms need to be very similar in format. The online portion also needs to be fully printable so that the end user can keep a copy for there personal records. Does anyone know of any ASP.NET controls, free or otherwise, that I could use to complete this functionality? Or what would be the best technology to solve this problem?
Not sure I see a question. This is more of my opinion of what you should do:
Im working on something similar. My form generator had a LOT of complicated fields and data to handle and I decided to go with silverlight. I very happy now, despite the learning curve, and the madness async api, because it would have just been hairy to do it with asp.net, pure asp.net with postbacks would just be bad UX and then putting ajax in between would've just been scary.
If you have great Ajax/asp.net experience go with it, but if not, Id suggest silverlight. I got up to speed pretty quick.
In my application, I have a situation wherein the users will need to have the flexibility to customize the UI to a certain extent. The following are some of the customizations that is being discussed now...
Change Label text associated with the with Use Input controls
Mark a control as Mandatory/Read only/Hidden
Assign a regular expression for the text box
Are there any recommended design patterns for my situation? Seems like I need to store all these in a database and worried about the performance impact if I have to read every element from the database for every page.
Thanks,
Harsha
I would look at some of the open-source CMS or portal systems written in ASP.NET and see how they are doing UI customization (if they are).
Phil Haack has some insight at the following article:
Scripting ASP.NET MVC Views Stored In The Database
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
Apparently it's not an easy thing to do in ASP.NET. It's easier to do in ASP.NET MVC, because the markup is cleaner and you can control it with jQuery.
The overall concept you are going for is not easy to have system wide, however the specifics you stated are fairly easy.
You'd have to setup some fields in a database for those values and then on the page load set those values on the page load. Pretty trivial from a 'how to'. Which your question shows that you 'get'.
Now unless you are using an Access Database :-), I don't think you have to worry about the performance hit. But if truly concerned, put some caching logic on those values so you only have to hit the database once. Though, be aware this will store the values in memory on the server, so if you are working with a very minimal hardware this could be an issue as well.
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
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Concerning pages that build a web application:
Lately, I have found myself creating web pages that are simpler than the ones I used to. Before, I would try to jam as much functionality into a single page as I could to prevent from having lots of pages.
I am starting to realize that this was just making things way more complex, convoluted, and confusing than it had to be. Why not have more pages? I think the reason that I was doing this was because I didn't want the user to have to browse to other pages; just to have all the functionality they needed on a single page.
Well, these good intentions turned into an overly confusing interface for the user and very unmanageable source code. I am a new developer and I am trying to be very reflective of what I am doing so that I can improve. If it makes a difference, I am developing in ASP.net (though these are probably considerations for any platform).
My questions are:
Am I overthinking these things?
Has anyone else found themselves doing this?
Where is the happy medium?
There is no expert who can give you a rule that works in all places at all times. I have been known in my industry for years for "easy" interfaces and we've won significant amounts of business for it (as well as 5 "Best in Class" awards). I have also had people within my company and outside of it tell me - for years - that they like my work but wish that I would "jazz it up" with more graphics and such. What always amazes me is how little connection people see between the two.
So...a few rules of thumb:
A page should do one main thing.
A page may well have multiple links related to the main thing
Menuing and link layout should be consistent across pages
Simpler is better than more complex
Pages should be visually appealing and inviting
Rule 4 is more important than rule 5.
For example, my product provides an interface that lets people define classes and events to be displayed in a calendar. I could have one page that lets you Review, Add, Update, Delete and Edit the classes. Indeed, in some simpler areas, I've used the gridview to let people manage everything in a grid. However, classes have too much information to do this and still follow the rules above.
So,
The main idea is: "Here is a list of classes for this location"
The links are "Add New" shown above and to the right of the grid, Change and Delete are links within each row. This is consistent across the app.
Menuing for the system as a whole is always across the right/top. Nothing else appears on the class/event page except for standard elements common to all pages (a logo, a header, a footer).
The grid is nicely styled but there are no spurious graphics (4,5,6)
A few last things about UIs and graphic design.
First, develop your own vision and be consistent across pages and apps.
Second, do not be afraid of simplicity.
Next, when soliciting advice from others keep in mind that you do not want their advice - you want their impressions: you want to understand the way they perceive the interface. Advice is sometimes good but, more often than not, actually harmful. In my experience, everyone thinks that they are a UI expert.
When you do your hallway (or formal) useability testing you should discount almost all advice to the effect that "you should make that stand out more." As you'll see, it will quickly become "and that," "and that," "and the other." If you follow this advice, you'll end up with a mess due to Brittingham's first rule of design: If everything is important than nothing is. (There you go: when explaining why you can't make someone stand out more, just tell them that "it violates Brittingham's first rule of design!")
Hope this helps!
You hit the nail on the head. Use the KISS principle. (Keep It Simple Stupid)
I've done this in the past as well and not only does it make for a hideous UI, but confusing as to what operations you can do on the page due to having too much functionality. I've often found in testing that I did not have enough checks to see if the user could perform a certain operation based on the state of the data.
It's easy enough in ASP.Net to write several pages that do simple tasks and then link them together with Response.Redirect or Server.Transfer. Now all I try to achieve on any given page is what the design specs say. So if my page is just a search page, that's all I give. If the user wants to see the details of an item that was returned in the search, then I send them to an itemDetails.aspx page.
You've broken a wall that most software developers have, the one that was blocking your view on usability before. A lot of developers don't really think about it and try to make it easier for them by stuffing functionality in one window, web page or whatever.
The thing is once you start designing software from the user's point of view, i.e. making it easier, several things start to become clear. One is the issue of code maintenance, that code is easily more managable to work on if you don't stuff everything in one giant class or whatever travesty you've been doing. The other is usability itself, that you start to think how the user is actually using your application through the graphical interface. Third is avoiding requirements or scope creep where you stop developing functionality that the user doesn't need.
We as users want simplicity partly because we don't want to spend most of our time muddling through a bad UI when we can get our work done faster with a simple and slick UI. That makes it for us software developers the right thing to do, to think through your design on all levels... that and specs always lie.
Definitely agree: most attempts at writing pages/forms that do too much have resulted in
bugs and rewrites. Problems occur with keeping all parts valid/synchronized,
excess managing of users' expectations ("I've entered a bill number here and clicked "find person" there but it gives an error message. Why?") when the two are logically separate. These questions cannot arise if only the valid options are visible,
Formatting/layout issues: In ASP.NET pages, trying to layout independent User Controls turns out to be a nightmare ("But we really want all the buttons vertically aligned!" in separate user controls. Good luck with that.)
I'd consider webpages with more than one functionality only if the target audience consists of domain experts, i.e. people that need lots of functionality on one page for better productivity (think data-entry or financial software with lots of variables).
Even then, most of the time, it's possible separate pages into single units.
No
Yes - me
I found the happy medium was to use Masterpages, and using it in a way that was familiar to IFrames. That I could have a lots of functionality combined well together. There is a more interesting way of doing this with WPF/Silverlight called Prism
The amount of functionality on a page is usually not determined by you but by your customer. If the customer demands a single page to update some VeryComplexObject, you're likely to end up with an aspx page that has a significant number of lines. Main reason is that you simply have a lot of event handlers for all actions on the page.
Whether that page is complex is entirely up to you. You should always attempt to make your code-behind file as simple and clean as possible. Some suggestions in that direction:
Move all business code to another application layer.
Use ObjectDataSource for providing data to data-bound controls such as ListView, GridView, Repeater, ... Delegating loading of data to a dedicated object prevents a lot of overhead in your aspx.cs file.
Another suggestion is to use user controls to implement portions of your page. You would usually only do this when you can reuse the user control, but it can also be of great help reducing page complexity (both of your code-behind file as well as your aspx).
Sometimes I think we are all guilty of forgetting just who it is that we develop our applications for. It isn't always easy as a developer to be able to take a step back and have a look at your application as a user might do so. This is why big companies employee hundreds of people to do this for them and they don't always get it right.
Usability is a massive subject but it is defiantly something that all developers need to keep in mind. It has taken me a long time to learn this but when tackling any development task I always try to think about how my users are going to interact with what I am writing. This will make a difference to all levels of your development.
I would suggest reading Don't Make Me Think by Steve Krug. This book won't take you an age to read and it puts across some fantastic ideas that can help you to develop applications that are much easier to use and understand.
I always find that once I have thought about the user experience the decisions about what my web pages are going to do and how they are going to interact are much easier to make.
Maybe you should ask the people who are using your site. Or better yet, just watch people use your site. I think that would tell you if your site is designed well, or if you need to change it.