asp.net Web forms internationalization - asp.net

I'm still pretty new to asp.net web forms. I have a requirement to make app available in two languages. Everything that has to be translated is static content. Can you point me to good reading resource on this topic or perhaps explain shortly how is this best done?

Video tutorial from microsoft asp.net team : http://www.asp.net/web-forms/videos/how-do-i/how-do-i-create-a-multi-lingual-site-with-localization
Here is another useful link : http://weblogs.asp.net/sreejukg/archive/2010/11/23/multi-lingual-web-applications-using-asp-net-4.aspx

The articles that were listed in the other answers are all great resources.
Here is a quick summary of some things to consider:
Any static text that will be "user facing" should be stored in resource files. In ASP .NET these files typically take the form of .resx files where the name of the file corresponds to the name of the page in which it is consumed. There are plenty of great articles out there for how to create and maintain these files. For each new language needed, you create a separate ..resx file. So if your "default" English text for a page is stored in 'MyPage.aspx.resx', you would store the Brazilian Portuguese translation in 'MyPage.aspx.pt-BR.resx'.
When creating your "default" resource entries (sometimes referred to as messages), it's important to try and keep your messages organized as complete sentences/thoughts, as those will be easier to translate to other languages. There are some great general guidelines for structuring localizable messages on the mediawiki.org site: MediaWiki - Internationalization Hints
You'll want to be very careful with respect to things like date and number parsing and formatting. The .NET framework provides good facilities for parsing and formatting dates and numbers in a variety of different cultural contexts. Most .Parse and .Format methods accept an instance of the CultureInfo class that it can use to inform .NET about how the number or date should be formatted.
Related to the above: I've found it easier to prefer ISO-friendly date formats whenever possible. Most people that see: '2010-03-05' would know that it represents March 5, 2010 while '03-05-2010' could be interpreted as March 5, 2010 or May 3, 2010, depending on where you're from. Again, the .NET framework provides facilities for you to properly format this date based on the culture preferences of the current user, but I've often found it easier to just pick a standard format that is internationally recognized whenever possible to make your life easier.
These are very high-level guidelines and there are a lot of other things to take into consideration when localizing software. I definitely recommend that you check out the articles linked in other answers, but some of the stuff I've listed above have bitten me in the past.

The .Net Framework supports Internationalization API which is known as Globalization and Localization. Globalization/Localization includes the country/region, calendars, number format, currency format, date format, resources, text encoding etc. Have a look at MSDN article on ASP.NET Globalization and Localization

Related

Translate website and internationalization

I have an application in ASP.Net in AngularJS, until then that my application had the need only in Brazil, but recently the company where I work needs to make this site available to other countries in other languages ​​like Spanish and English.
I have never worked with International applications, so there will be many doubts and difficulties.
I'll start with the difficulties:
- My application has fixed texts in the html, database and code, how can I translate all these fronts? Is there a component that translates everything into the client? (Javascript, AngularJS, etc ...).
- Development time for this change (Too much code to change).
Questions: - Decimal, Date and Time, how to work with these values ​​in an International application? (My application has many logs and values ​​to display and insert)
I'm researching a lot but really needed a hint of where I could go.
Thank you, I'll wait!
I would start searching for "Localization". There is something called "AspNetBoilerplate" that has implemented localization into there project. Here is their link: https://aspnetboilerplate.com/ and here is document on how to use it within their project: https://aspnetboilerplate.com/Pages/Documents/Localization. You can easily download a free project and see what they did to implement it.
They have different localization files based on language being used. The language being used is a setting in the DB based upon the tenant that logs in. All static text looks up to its respective localization file (See their .Core project under "Localization" to see all their files).
As far as DateTimes/Decimals/etc, I would have extension methods that looked up the cached localization being used and format respectively.
By no means am I recommending you use this software but rather see how they implemented it within their project. Also, know that I have only had to do this once and there may be numerous other ways to accomplish this goal.

Website translation architecture and implementation

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

Localization - First Steps

I'm pretty much after people opinions/best practices and nuggets of experience here.
I need to produce a new website in ASP.net C# which has the requirement of changing the language based on the user profiles.
I've done a couple of simple samples before but I'm curious on a slightly lower level. I'm after resources which I can read and review really.
What design patterns are in place for doing things like translating grids of data into different cultures.
If I'm going to store currency info, is it standard practice to store the exchange rates also?
If I'm going to down the route of a standard ASP.net web application can I use URL routing to help pick the culture to use? for instance www.mynewsite.com/en-GB/default.aspx.
Wisdom/Thoughts welcome.
Thanks for looking and thanks more for answering,
Mike
A couple of things that I've learned:
Absolutely and brutally minimize the number of images you have that contain text. Doing so will make your life a billion percent easier since you won't have to get a new set of images for every friggin' language.
Be very wary of css positioning that relies on things always remaining the same size. If those things contain text, they will not remain the same size, and you will then need to go back and fix your designs.
If you use character types in your sql tables, make sure that any of those that might receive international input are unicode (nchar, nvarchar, ntext). For that matter, I would just standardize on using the unicode versions.
If you're building SQL queries dynamically, make sure that you include the N prefix before any quoted text if there's any chance that text might be unicode. If you end up putting garbage in a SQL table, check to see if that's there.
Make sure that all your web pages definitively state that they are in a unicode format. See Joel's article, mentioned above.
You're going to be using resource files a lot for this project. That's good - ASP.NET 2.0 has great support for such. You'll want to look into the App_LocalResources and App_GlobalResources folder as well as GetLocalResourceObject, GetGlobalResourceObject, and the concept of meta:resourceKey. Chapter 30 of Professional ASP.NET 2.0 has some great content regarding that. The 3.5 version of the book may well have good content there as well, but I don't own it.
Think about fonts. Many of the standard fonts you might want to use aren't unicode capable. I've always had luck with Arial Unicode MS, MS Gothic, MS Mincho. I'm not sure about how cross-platform these are, though. Also, note that not all fonts support all of the Unicode character definition. Again, test, test, test.
Start thinking now about how you're going to get translations into this system. Go talk to whoever is your translation vendor about how they want data passed back and forth for translation. Think about the fact that, through your local resource files, you will likely be repeating some commonly used strings through the system. Do you normalize those into global resource files, or do you have some sort of database layer where only one copy of each text used is generated. In our recent project, we used resource files which were generated from a database table that contained all the translations and the original, english version of the resource files.
Test. Generally speaking I will test in German, Polish, Hebrew or Arabic, and an Asian language (Japanese, Chinese, Korean). German and Polish are wordy and nearly guaranteed to stretch text areas, Asian languages use an entirely different set of characters which tests your unicode support, and Hebrew and Arabic are both right to left languages.

What is system.globalization And what's the difference between it and localization

and to spice things a bit , what is the best approach for globalization in Asp.net Mvc App
Globalization is about producing a map from strings or identifiers to translations in other languages, while Localization is about using that map to find the correct translation. Globalization happens during development, localization happens at runtime.
I'm not very experienced doing this with ASP.NET, but...
As for how, the most common approach I see is to have a dictionary per language per assembly (or per UI component), where the values are localized strings. The keys are typically readonly members on a static class or enum. There is often a convenience class whose members are the map from identifiers to localized messages.
The dictionaries are typically stored in separate files and in a format targeted to human translators.
More here: http://msdn.microsoft.com/en-us/library/aa478974.aspx
From the W3C I18n FAQ:
Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a "locale").
Internationalization (or globalization) is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.
I've never globalized an ASP.NET MVC application, so sorry if I can't help you there.
The System.Globalization namespace
contains classes that define
culture-related information, including
the language, the country/region, the
calendars in use, the format patterns
for dates, currency, and numbers, and
the sort order for strings.
As for what's the difference between it and localization? I guess that can be explained as the difference between a car and a city. One is a destination and the other is how you get there.
I haven't used ASP.NET MVC, but I have used Monorail which is similar. If I wanted to localize a MR app, I would probably use a separate tree of view files. So while, for english-only, I'd have:
\Views\Home\*.asp
\Views\Admin\*.asp
\Views\Products\*.asp
for an internationalized app, I'd have something like:
\en\Views\Home\*.asp
\en\Views\Admin\*.asp
\en\Views\Products\*.asp
\de\Views\Home\*.asp
\de\Views\Admin\*.asp
\de\Views\Products\*.asp
\es\Views\Home\*.asp
\es\Views\Admin\*.asp
\es\Views\Products\*.asp

Storing content in multiple languages? E.g. English, French, German

How should I store (and present) the text on a website intended for worldwide use, with several languages? The content is mostly in the form of 500+ word articles, although I will need to translate tiny snippets of text on each page too (such as "print this article" or "back to menu").
I know there are several CMS packages that handle multiple languages, but I have to integrate with our existing ASP systems too, so I am ignoring such solutions.
One concern I have is that Google should be able to find the pages, even for foreign users. I am less concerned about issues with processing dates and currencies.
I worry that, left to my own devices, I will invent a way of doing this which work, but eventually lead to disaster! I want to know what professional solutions you have actually used on real projects, not untried ideas! Thanks very much.
I looked at RESX files, but felt they were unsuitable for all but the most trivial translation solutions (I will elaborate if anyone wants to know).
Google will help me with translating the text, but not storing/presenting it.
Has anyone worked on a multi-language project that relied on their own code for presentation?
Any thoughts on serving up content in the following ways, and which is best?
http://www.website.com/text/view.asp?id=12345&lang=fr
http://www.website.com/text/12345/bonjour_mes_amis.htm
http://fr.website.com/text/12345
(these are not real URLs, i was just showing examples)
Firstly put all code for all languages under one domain - it will help your google-rank.
We have a fully multi-lingual system, with localisations stored in a database but cached with the web application.
Wherever we want a localisation to appear we use:
<%$ Resources: LanguageProvider, Path/To/Localisation %>
Then in our web.config:
<globalization resourceProviderFactoryType="FactoryClassName, AssemblyName"/>
FactoryClassName then implements ResourceProviderFactory to provide the actual dynamic functionality. Localisations are stored in the DB with a string key "Path/To/Localisation"
It is important to cache the localised values - you don't want to have lots of DB lookups on each page, and we cache thousands of localised strings with no performance issues.
Use the user's current browser localisation to choose what language to serve up.
You might want to check GNU Gettext project out - at least something to start with.
Edited to add info about projects:
I've worked on several multilingual projects using Gettext technology in different technologies, including C++/MFC and J2EE/JSP, and it worked all fine. However, you need to write/find your own code to display the localized data of course.
If you are using .Net, I would recommend going with one or more resource files (.resx). There is plenty of documentation on this on MSDN.
As with most general programming questions, it depends on your needs.
For static text, I would use RESX files. For me, as .Net programmer, they are easy to use and the .Net Framework has good support for them.
For any dynamic text, I tend to store such information in the database, especially if the site maintainer is going to be a non-developer. In the past I've used two approaches, adding a language column and creating different entries for the different languages or creating a separate table to store the language specific text.
The table for the first approach might look something like this:
Article Id | Language Id | Language Specific Article Text | Created By | Created Date
This works for situations where you can create different entries for a given article and you don't need to keep any data associated with these different entries in sync (such as an Updated timestamp).
The other approach is to have two separate tables, one for non-language specific text (id, created date, created user, updated date, etc) and another table containing the language specific text. So the tables might look something like this:
First Table: Article Id | Created By | Created Date | Updated By | Updated Date
Second Table: Article Id | Language Id | Language Specific Article Text
For me, the question comes down to updating the non-language dependent data. If you are updating that data then I would lean towards the second approach, otherwise I would go with the first approach as I view that as simpler (can't forget the KISS principle).
If you're just worried about the article content being translated, and do not need a fully integrated option, I have used google translation in the past and it works great on a smaller scale.
Wonderful question.
I solved this problem for the website I made (link in my profile) with a homemade Python 3 script that translates the general template on the fly and inserts a specific content page from a language requested (or guessed by Apache from Accept-Language).
It was fun since I got to learn Python and write my own mini-library for creating content pages. One downside was that our hosting didn't have Python 3, but I made my script generate static HTML (the original one was examining User-agent) and then upload it to server. That works so far and making a new language version of the site is now a breeze :)
The biggest downside of this method is that it is time-consuming to write things from scratch. So if you want, drop me line and I'll help you use my script :)
As for the URL format, I use site.com/content/example.fr since this allows Apache to perform language negotiation in case somebody asks for /content/example and has a browser tell that it likes French language. When you do this Apache also adds .html or whatever as a bonus.
So when a request is for example and I have files
example.fr
example.en
example.vi
Apache will automatically proceed with example.vi for a person with Vietnamese-configured browser or example.en for a person with German-configured browser. Pretty useful.

Resources