We are going to develop an ASP.NET website in 30 language.
What is the best solution for developing that site? which architecture to be used?
I suggest storing UI properties in resource files (.resx) and have the CurrentUICulture to the specific language for each request:
<globalization culture="auto" uiCulture="auto" />
If your Web site is mostly content-oriented rather than a business oriented application that differs heavily based on the language, you might want to consider building separate set of pages for each language and redirect the user based on a cookie or profile property or Request.UserLanguages. It's not possible to give a general prescription for globalization problem. The best architecture differs significantly based on the nature of each individual project.
NLS is a recurring requirement, and often when the question about NLS functionality is asked, the people asking are not aware of the complexity. NLS typically split into (at least) 2 areas:
NLS in the UI
NLS in the data
In your case, a content-based website, you may even split the second point into - data generated by the website provider and - user generated data.
For UI NLS you can use the .resx mechanism as mentioned by Mehrdad, but you should be aware that every work on localization always requires to edit the source code (i.e. the resx files).
When I had to develop a multi-languge web app, I therefore chose to handle the NLS requirement in my code, and created a couple of NLS-specific tables that mirrored the UI (btw this was the motivation to write graspx: extract all visible texts from aspx source, such as Label.Text etc). There is a separate application to upload the UI definition, and let translators do their work. The main application has an import functionality for the translated texts.
The data model looks like this: Page - PageItems - PageItemTexts (with reference to a Language), so it's quite simple.
The same model can be applied to the content: instead of Page and PageItems, you simply have ContentItems, which hold a PK and a identifier only, and a table holding the text of the ContentItems associated with a language.
Additionally, you may define some sort of language fallback chain, so that a text which is not yet translated is displayed in the original language, or some other (closely related) language.
The displayed language can be selected by the language provided by the browser (HTTP_ACCEPT_LANGUAGE), but should be allowed to be overwritten by the user (e.g. via a combobox). The selected language should be stored in a session variable, in a cookie, or in the database (for registered users).
Related
I have one challenging task. I want an application form that is in completely in XML
(with xslt).Application having textbox,dropdown list, checkbox etc.
First of all user will download this application form (XML).then user fill this form.
when user fills this form the data should be stored locally. and when i upload this file to server, all the data will be saved in my database.
Is it possible ??
This is recognized as a desirable feature. It makes sense that given an XML schema it should be possible to utilize this to take some of the development effort out of form filling and submission. The specification is known as XForms. I looked at this about ten years ago and it was really immature. I can only suggest that you google XForms and see if there are any toolkits that suits your needs. Otherwise you will have to hand code the functionality yourself. As far as I know the XForms specification is not supported directly in any browsers.
I am trying to come up with a way to automate testing of localized UI in ASP.NET WebForms. Basically I have button that toggles the current locale and code that populates the right text from resource file. The problem is how to test it.
One approach is to use BDD in a form of
As a Spanish speaking user
I want to switch to Spanish
So that I can use the site more comfortably
Scenario Outline:
... a bunch of steps to get each possible string (labels, buttons, messages, etc)
Another approach is to use TDD in a form of row based tests and check each property (which is WebForms is not trivial).
The first approach forces repeating existing scenarios, the second is very difficult and not clear.
How do people test localization?
Well I am in the same boat at this moment...
What I am trying to do.. is
to extract the user-visible strings used by the automated tests out into a swappable block (in my case this is a .net resource file). The idea is to have different machines (or VMs or change at runtime) and run the same suite across different localized versions of the app.
That leaves the switch language feature (that we don't support at the moment): that you could test by exercising the switch behavior and doing a cursory check in a test.
Finally you really need a set of human eyes to ensure everything has been localized and is accessible (e.g. not clipped and stuff). There are other aspects too that can't be automated.. e.g. the use of colors to signal alarms.
To ensure there are no hard coded user-visible strings, create a junk resource file with junk characters, wire it to the app and manually breeze through all the screens periodically (every 2 weeks). If you still see english strings, something still resides out of the resource file. Once everything is in the resource file, you still need someone who speaks the language to ensure that the localized strings appear correctly or match the context in which they are shown.
I'm conducting a project in which a website should have multi-language support.
Now, this website is supposed to serve about 500K+ visitors a day, so it must be super-efficient.
I've created a table of parameters {[ID],[Name]} AND a linkage-table {[objectID],[parameterID],[languageID],[value]}. I think it's the best way to deploy multi-language support while having the privilege to translate different parameters for each language.
As far as I know, server's memory is much faster than a physical HDD. Therefore, I'm planning to store ASP.NET Application State objects for my translation architecture.
(http://msdn.microsoft.com/en-us/library/ms178594.aspx)
How does my plan sound so far? any suggestions?
If you are planning on making an app that support multiple languages, your instant reflex should be let .net do the work for you. What i'm reading in your question is that you are setting up something to support that. You should know that localization is the way to go when you want to develop a multi-language environment.
Take a look at this msdn article, it should give you a general idea on the topic.
So, localizing an application can be divided into two parts:
Localizing business logic entities.
Localizing everything else.
In the question I see words which are related to business entity localization. For that purpose I agree with the concept to have separation between entities and their localizations.
Part 1 - Localizing entities:
Personally I do this way in database:
table Entity {EntityID, Name} -this is the entity-related table.
table EntityByLang {EntityID, LanguageID, Name} -this is the localized version of the table for each supported language.
This way allows me to have default values for each localizable property like Name and its localization, if such is available in the localized table. What's left here up to you is - you need to implement the data-access-layer which takes the Name localized for the current user language, or the default value (if language or the translation is not available for the given language).
Part 2 - Localizing everything else:
Here, with no alternatives in terms of the performance, I would recommend using some kind of static resources. Personally I live with static resources available for standard asp.net applications.
From the architectural point of view, don't directly refer to localization code from your UI code, like this (which I don't like):
var translation = HttpContext.Current.GetGlobalResourceObject("hello");
//excuse me, if I don't exactly remember the GetGlobalResourceObject() method name...
Instead, I would recommend using this kind of approach:
var translation = AppContext.GetLocalizationService().Translate("hello");
Where: AppContext - some kind of facade/factory (in fact, implementation of abstract facade/factory). GetLocalizationService - initially returns some kind of ILocalizationService, when implemented it returns StaticResLocalizationService (which implements ILocalizationService). This way allowing switching from one kind of localization to another. And particularly StaticResLocalizationService works with asp.net static resources
Sorry for messy sample codes, but I hope you understand my approach.
I hope this helps!
I would suggest to create custom resource provider, you can read more here:
http://msdn.microsoft.com/en-us/library/aa905797.aspx
with this model you can leverage existing asp .net localization functionality
I'm trying to get a high-level understanding of ASP.Net MVC, and it has started to occur to me that it looks a lot like the original ASP script. Back in the day, we were organizing our "model"/business logic code into VBScript classes, or into VB COM components.
Of course, now we have the additional power of c# and the .net framework classes. Besides the high-level oo and other capabilities in c# and .Net, what are the other major differences between the original ASP and ASP.Net MVC?
There are three main differences: URL mapping, separation of logic from presentation, and strong typing.
URL Mapping
With classic ASP there is a smooth transition from writing HTML pages to writing HTML pages with dynamic content. As with static HTML files, each URL has a direct mapping to a file in the filesystem. The same thing is more or less true of ASP.NET, for what it's worth.
In ASP.NET MVC, each "family" of URLs maps to a Controller object (stored in the /Controllers directory, by default), where each member of the family calls a method when accessed. At the end of each method (typically), you tell it to render a particular view (stored in a folder named after the controller in the /Views directory), which is a lot like a classic ASP page with all of the logic separated out.
This gives you logical and SEO-friendly URLs and groups related functionality together.
Separation of Logic from Presentation
In classic ASP it's common to find pages where a bit of HTML is included at the top, and then a database connection is opened and some things are read from the database while being output to the user, and then some more html, and then another database statement, and so on.
In ASP.NET MVC, your business logic (e.g. validation) goes in the model layer (you can choose from one of several dozen, but popular choices are LINQ-to-SQL and LINQ-to-Entity-Framework), your human interface logic goes in the controller (e.g. populating a State/Province menu based on the Country selection), and your presentation (the actual HTML you can hand to a designer to edit) goes in the view.
Aside from keeping things organized, this helps a great deal with being able to write automated tests for things. You can send a mocked-up object to your view and make sure it looks good, you can send bad data to your model and make sure it complains, and you can make sure that the object your controller sends out to your view is consistent with what it reads from the model.
Strong Typing and Compilation
ASP.NET is strongly typed and compiled. This is a double-edged sword. On the one hand, it will catch a lot of stupid programmer mistakes at compile time. On the other hand it, that means you're left with "infinity minus one" possible errors in your code (unit testing can make it infinity minus some larger number). Also, you'll have to do things like:
if (MyArray.Length > 0)
rather than
if (MyArray.Length)
But IMHO that's a small price to pay for the speed and sanity-checking you get from strong typing.
The bigger downside to compiled languages in a big framework is that deployment becomes much more of a production than it is with something like Classic ASP. You can't just copy a couple of files to the web server to update your app. You typically have to take the webserver down (hopefully you have a redundant pair) and recompile, which can take minutes.
ASP.NET MVC has a lot of plumbing infrastructure: for example, the routing engine which automatically invokes the right controller and action and can extract bits from the URL to pass as action arguments; or the convention-based location of views. It also provides more structure for passing data from the controller into the view (the ViewData object).
Also, crucially, MVC supports view engines. You can write raw HTML with helpers in it, but you can also use view engines like Web Forms, Spark, NHaml, etc. which allow you to write more concise view code, create reusable components (e.g. Web Forms controls), etc. This wasn't possible in ASP Classic.
Classic ASP used VBScript, which does not have classes. It's not object-oriented at all.
Very often with different technologies we can achieve the same
final result.
To create simple sites is almost irrelevant to the choice of technology.
But when you want to make a large complex site the presence or absence of a framework that allows to optimize the code, keep well organized and efficiently divide may play a role
crucial and greatly reduce the work.
ASP Classic does not achieve the same results reached by asp
net mvc.
If we omit the obvious differences between c # vb script I would say that the difference
main is that you can keep your code better organized.
As with classic ASP is very easy to make "spaghetti code and, with asp
mvc, on the contrary, it is very easy to keep everything tidy and separate the code
business logic from display.
Not only that.
Asp Net Mvc seamlessly integrates with technologies such as that EntityFramework
allow a further breakdown and organization of the code.
As the question is a bit self explanatory, I want to achieve the goal of a multi-language website. I am using an Entity Data Model with MS SQL 2005. I came up with an idea of making a seperate database for each language with exactly the same model and relations. So I can use the Entities constructor that takes a connectionString and switch the site to the selected language.
I am using an ascx as the language control that fires an event, and the parent aspx gets the selected language as an integer (from event args) and call the method containing the same linq queries but Entity context will be created with the connection string of that db (of language)
I could only came up with this solution, because I think adding a new language will require a replication of the english one, imported to Access and sent to the translator. Then will be exported back, and the model will fit (HOPEFULLY).
My question is if this is really a good approach or am I missing anything that will create greater hassle to me. Thanks in advance
multi-database is not a good solution as soon as entities within the different databases have relations to each other. Generally a good approach is to work with labels in one default language. These labels can either be in a well defined format (e.g. 'LABEL.TEXT_HELLO') or just in the base language (e.g. 'Hello World').
So all you have to do is building a table for translations where the base language is the key and hopefully there is for each key a value containing the translation. As soon as you have the translations, you can write a method ont he frontend which writes the labels in the language used by the user.
In Zend Framework for example, you have to write <h1><?= $this->translate('Hello World'); ?></h1> instead of just <h1>Hello World</h1>
The good thing about that is, that if ya translation is missing, you can still use the fallback (in this case english) to show the user at least something.
That way, you can manage your app in one database and users who speak several languages do not have to switch between applications and content.
cheers
My approach: create a table Language that lists all the available languages. Relate each table that should be localized to Language. Now, you can easily access the localized content e.g.
Content[content_ID].HeadLine.Where(hl => hl.Language.id == "en-US")
I look forward to see what other people as I myself is still learning DB design and EDM.
OK, if you want to be able to easily implement a new language, then reinventing the internationalization features already built in to ASP.NET is not the way to go, because it isn't "easy".
At least, not as easy as using a satellite resource DLL. Your translators will use off-the-shelf tooling to translate your resources, and ASP.NET will automatically select the correct DLL based on the user's current culture.
Read up on ASP.NET internationalization/globalization features; there's no need to invent your own.