For an wide application, I need to use localization. I'm planning to use this method for the localization: http://geekswithblogs.net/shaunxu/archive/2010/05/06/localization-in-asp.net-mvc-ndash-3-days-investigation-1-day.aspx
But for this project I also need to use Area, which are defining their own files.
Is there a way that I can use to not redefine the language variable in URI (the {lang} in area?
I feel like I've to redeclare each time how the localization using the url works, and this seems to be bad to me.
What can I do to avoid this?
In terms of SEO using an url parameter for localization is the best. The drawback is that you will have to define it for all your urls. Another possibility is to use cookies or session to store the current language in which case you don't need to pass it to all urls. Here's a guide which illustrates this. Easier to develop but not good for SEO.
Related
I'm working on a website that will deployed internationally. Very big site, but for the sake of simplicity, all we're concerned about is my Error.aspx with c# code behind. I'd like to make this custom error page as dynamic as possible. There's at least a handful of languages we need to read this page in right now, and more to come. This page needs to work independently and without a database to reference.
I'd like to have some text, and have the appropriate translation appear based on the language appropriate for that domain... e.g. ".com" = English, ".ca/fr" = French, ".mx" = Spanish... you get the idea.
What's the best way to do this?
I've looked into API's, but the decent ones have a cost threshold, and while it might look really helpful, this is just pretty standard error message text, that's unlikely to change, so that seems like overkill to have a dynamic translator. It might help with scalability, but it's extra money indefinitely, when it will only save vs hard-coding on the handful of occasions where we add another language/country/domain.
The other idea I had was to simply hardcode it in the c#. parse out Request.URL and get the domain, and make a ever-growing switch statement which would assign the appropriate text. (As an aside, I'm also trying to find a better way to do this, but is the country code something that would be an available piece of information from either the request object or server?) This way would be independent, precise, and the only drawback on a concrete level would be the cost of adding new languages, or changing every string (probably not that many, at least at first) if the content of the error message needed to be adjusted. But this feels like bad practice.
I've been researching this for a day now, but I haven't found any alternatives to these 2 options. What are the best practices for handling small amounts of text for translation, without the use of a CMS?
There is an easy built-in way to handle localization in ASP.NET Web Forms. It uses the Language Preference settings in the client's browser to select the language. Posting the steps of setting it up would be redundant since there's lots of information on this subject available online. Here is a good tutorial.
EDIT:
It might be a good idea to read up on HTML resource files. That is the HTML standard for handling different languages (referred to as localization). And it is what ASP.NET uses in the background when creating a local resource for a server control.
I apologize in advance for the generic nature of my question, but I was unable to find any helpful advice from people trying to do the same thing as me on the web. Let me describe my scenario:
I am providing end users/designers of a website the ability to customize their views by storing the views (using Razor) in the database. I have all of this working, but my question is the following; From a security standpoint, how can I ensure and enforce that unwanted code doesn't get executed in the user-defined view? There are two basic approaches that I think will work conceptually, but am not sure which one is more possible or feasible.
Option 1: Create a validation method in the administration tool that allows the user to input the view code. This would need to either take a whitelist or blacklist approach to what is allowable or not.
Option 2: Prevent unwanted code from being able to execute when rendering of the view occurs.
As a quick example of something that would need to be blocked, we wouldn't want to allow access to read or write files, access any data access functions, or even access configuration settings, etc. in the web.config. There will likely be a decently-sized list of things that probably shouldn't be allowable, but I'll need to sit down and try to think of as many security-related concerns as possible.
My question then is, which method would be the best bet? Also, can any direction be provided on how to go about either? I thought I might be able to make trust-level based change which would be Option 2, but couldn't find any way to make that work in a per-view based manor (the administration code is allowed to execute whatever it wants). I'm thinking Option 1 will end up being the best bet and I'll have to check for the input of certain framework functions that shouldn't be allowed. Does anyone have any experience doing anything like what I'm trying to do? ANY feedback is much appreciated!
This would be extremely difficult.
You could run the the template through the Razor preprocessor, then use Roslyn (still in early beta) to parse the generated file and look through all method calls (or constructors) and return an error if it calls something you don't like.
I strongly recommend that you use a whitelist for that, since the .Net framework is big enough that you are bound to overlook something in a blacklist.
However, I would instead recommend that you not use Razor at all and instead use a templating engine that does not allow real C# code.
This is the scenario: I have a list of about 5000 URLs which have already been published to various customers. Now, all of these URLs' location has changed on my server side. The server is still the same though. This is a ASP.NET website with .NET3.5/C#.
My requirement is : Though the customers use the older source URL they should be redirected to the new URL without any perceived change or intermediate redirection message etc.
I am trying to make sense of the whole scenario:
Where would I put the actual mapping of Old URL to New URL -- in a database or some config. file or is there a better option?
How would I actual implement a redirect:
Should I write a method with Server.Transfer ot Response.Redirect?
And is there a best practice to it like - placing the actual re-routing in HTTPModules..or is it Application_BeginRequest?
I am looking to achieve with a best-practice compliant methodology and very low performance degradation, if any.
If your application already uses a database then I'd use that. Make the old URL the primary key and lookups should be very fast. I'd personally wrap the whole thing in .NET classes that abstracts it and allow you to create a Dictionary<string,string> of all the URLs which can be loaded into memory from the DB and cached. This will be even faster.
Definitely DON'T use Server.Transfer. Instead you should do a 301 Permanently Moved redirect. This will let search engines know to use the new URL. If you were using NET 4.0 you could use the HttpResponse.RedirectPermanent method. However, in earlier versions you have to set the headers yourself - but this is trivial.
Keep the data in a database, but load into ASP.NET cache to reduce access time.
You definitely want to use HTTPModules. It's the accepted practice, and having recently tried to do it inside Global.asax, I can tell you that unless you want to do only the simplest kind of stuff (i.e. "~/mypage.aspx/3" <-> "~/mypage.aspx?param1=3) it's much more complicated and buggy than it seems.
In fact, I regret even trying to roll my own URL rewriting solution. It's just not worth it if you want something you can depend on. Scott Guthrie has a very good blog post on the subject, and he recommends UrlRewriter.net or UrlRewriting.net as a couple of free, open-source URL rewriting solutions.
Good luck.
My situation is. I have a project planned to be built on ASP.NET MVC 2. And one of the major requirements is SEO optimization. A customer wants to use static-like URLs that end up with .html extension for this project that make URLs more SEO friendly. E.g. "mysite.com/about.html " or "mysite.com/items/getitem/5.html" etc.
I wonder is there any benefit from SEO perspective to use .html extension in dynamic URLs? Are Google and other search engines rank work better with such URLs?
I would use sitemaps instead, this enables you to have dynamic content (and to use MVC) but still be crawled completely.
See: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=156184
and http://www.codinghorror.com/blog/2008/10/the-importance-of-sitemaps.html
No, the base URL doesn't matter. If you're serving dynamic content in .aspx or .html, it's all the same. If you do serve ASP.NET content with .html because of requirements (as dumb as they may be), then I suggest finding an alternative extension (e.g. .htm) for all static content. You don't want your static HTML files getting processed unnecessarily.
As Femaref said, you can use sitemaps to help.
Also, make sure your URL doesn't change (including variables) if the content is the same. This shouldn't be a problem with MVC.
Edit: In your example:
mysite.com/items/getitem/5.html
I'm guessing what you originally wanted is:
mysite.com/items/getitem/5
No extension doesn't make a difference either. Since that's not a problem, I would also argue that an extension makes the URL less "clean" and also suggests that there is a file called 5.html in that path, which is obviously not true.
Search engines don't care at all at what your webpage extensions look like.
If anything all you're doing indicating a file type for the page served up.
Can the page be reached?
Is there content?
Are there links pointing to that page?
That's what a search engine is worried about. Anyone can create a custom solution using custom file extensions for a website and have it work just fine.
I am interested in the architecture of a CMS where i can pass a full URL instead of a query string.
I would like to make a site that could handle a request to any page... Say
'http://www.my-domain.com/directory/page.aspx'
and have the resulting response deliver a generic page/file.
I would like the request to be passed through an XML document where i could store page names and the corresponding file to render content...
My question specifically
Is this possible
Is it easy to do
Are there any Links people have on
hand they could share with me on the
how to's.
Any pro's or
cons you may have come across if you
have used this method.
Yes, it's possible, and reasonable easy. Most CMSes do it this way, but use a database instead of an XML file.
You should probably look into URL rewriting. The concept is to separate the URL structure from the actual filesystem representation.
For .NET: UrlRewriting.Net is a gem.
However, since there are hundreds of fantastic CMSes already out there like you describe, I'd suggest using one of them and saving yourself work. Provide more detailed requirements and I can suggest one.