I am working on a web forms application that needs to support multiple languages based on a user's preference. Here are some considerations to keep in mind about the needed solution:
I want to avoid using resource files to store the different text translations because I'd like the ability to change them without having to recompile and deploy the application.
Also the translations ideally need to be adminstratable.
It seems its a considerable amount of effort to add this support to an existing application. Any suggestions would be appreciated. Thanks.
Rick Strahl has and awesome solution that is free for personal use, src available here via SVN:
West Wind Web & Ajax Toolkit for ASP.NET
Data Driven Localization Resource Provider
Database driven Localization lets you store resources in a SQL Server database.
Interactive Web based Resource
Adminstration provides a live Web
based adminstration for that can edit
and update resources while the app is
running
Resource Editing Control associates
icons with each localizable control
and allows jumping directly to the
administration form with the current
resource id and locale selected.
Resx Import and Export lets you
import existing Resx resources,
interactively edit them with the data
driven provider, then export them
back out as Resx resources.
Localization Utilities like a
JavaScript Resource Handler,
functions to embed localized script
values and much more.
You'll need languge tables for each supported language. You may need to start with an "en" table as your base language for the app.
Then you can add tables for en-gb, en-us and if required you can even go brand specific using custom cultures like en-gb-MyApp1, en-gb-myApp2
Make extensive use of caching and write a custom resource provider.
I blogged about my design of an E-commerce store where products, pages etc. are stored in database, and saved in multiple languages by storing column data in XML format.
Related
As at 2013 what is the best practice for multi language multi culture localization of web pages.
Should I store all the translations in a database? for language etc?
Should I build resx files based on a database query or should I simply create resx files?
The application will be used with a browser interface across multiple devices and platforms e.g. Windows/IOS/Android. Are there any additional things I should think about.
best regards
Shrekito
There are a few types of global content you will usually have to deal with:
Application templates such as HTML pages, menus, and emails sent by your app
Dynamic content stored in your database
App templates
Templates are typically handled using your own framework's internationalization (i18n) framework. In the case of asp.net, the framework includes libraries to mark strings and export them to (English) .resx files. This supports a lot of built-in features such as variables, plurals, and developer comments. So unless you're facing some actual blockers, you typically want to go with it instead of building your own i18n framework (eg. in-database, or in-DB with .resx export).
Nowadays, the workflow decisions come when you actually want to get those files localized. In the old days you'd exchange the files with an agency using email. In 2013, web apps have a fast-paced development cycle with multiple releases per week (or per day), so there is a much bigger need for automation. Teams are switching away from using a VCS, FTP or Dropbox as a temporary storage for their files to modern localization (L10n) management platforms like Transifex (discl: I'm the founder) to manage their localization process.
The best way to remove the L10n pain from developers is to integrate your L10n platform with your build tools, so whenever you commit something, the English files are sent automatically to the L10n system, which will detect the changes and notify the right translators. When you're ready to deploy, your integration will pull the fresh translated files automatically.
With Transifex, you can use the Tx Client app with a git-commit hook, your build/CI system or your ol' good deploy script:
tx push --source
tx pull -l de,fr,it --mode=reviewed --minimum-perc=90
Dynamic and External content
This type of content is typically not handled using .resx files since it's easier to manage it in your DB itself. Typically, you want to store this content along with your template content so that translators have a single place to look at everything.
The platform you choose will need to have a modern API to work with. Check out the Transifex API on how these look like.
Other tips and tricks
Choose a platform which has a strong built-in web-based translation editor. Translators need solid features such as Translation Memory, Glossary, Machine Translation to deliver quality and consistent translations.
Follow good i18n practices such as good date formatting and avoiding concatenation.
Love your translators. They're the ones who make it all happen.
At my office, we have had a long-standing debate about Localization/Globalization and how to handle it. One side pushes for the Resource (.resx) file route built in to ASP.NET, one side pushes for a database driven solution. A third group believes in rolling a custom solution.
Of course, each method has its own unique benefits and disadvantages - and we've discussed it over and over, without ever coming to a real consensus.
So, I pose it to the community: in your experience, which method provides the best mix of the following as the application grows:
Maintainability
Extensibility
Performance / Scalability
In addition to just advice, we'd also be interested in any open source projects which might help to simplify the question, as well. Thanks!
Rick Strahl (An MS MVP) has a great tool kit for managing localization via the DB - offer the ability to update and modify on demand through a controlled environment and does much of the heavy lifting for you. Histoolkit offer the following features:
Data Driven Localization Resource Provider
Database driven Localization lets you store resources in a SQL Server database.
Interactive Web based Resource Adminstration provides a live Web based adminstration for that can edit and update resources while the app is running
Resource Editing Control associates icons with each localizable control and allows jumping directly to the administration form with the current resource id and locale selected.
Resx Import and Export lets you import existing Resx resources, interactively edit them with the data driven provider, then export them back out as Resx resources.
Localization Utilities like a JavaScript Resource Handler, functions to embed localized script values and much more.
He also summarises the issues very well here (Ive pasted some good bits here - not my own work!)
To Resx or not to Resx
The default resource storage mechanism in .NET
uses Resx based resources. Resx refers to the file extension of XML
files that serve as the raw input for resources that are native to
.NET. Although XML is the input storage format that you see in Visual
Studio and the .Resx files, the final resource format is a binary
format (.Resources) that gets compiled into .NET assemblies by the
compiler. These compiled resources can be stored either alongside with
code in binary assemblies or on their own in resource satellite
assemblies whose sole purpose is to provide resources. Typically in
.NET the Invariant culture resources are embedded into the base
assembly with any other cultures housed in satellite assemblies stored
in culture specific sub-directories.
If you’re using Visual Studio
the resource compilation process is pretty much automatic – when you
add a .Resx file to a project VS.NET automatically compiles the
resources and embeds them into assemblies and creates the satellite
assemblies along with the required directory structure for each of the
supported locales. ASP.NET 2.0 expands on this base process by further
automating the resource servicing model and automatically compiling
Resx resources that are found App_GlobalResources and
App_LocalResources and making them available to the application with a
Resource Provider that’s specific to ASP.NET. The resource provider
makes resource access easier and more consistent from within ASP.NET
apps.
The .NET framework itself uses .Resx resources to serve
localized content so it seems only natural that the tools the
framework provides make resource creation tools available to serve
this same model.
Resx works well enough, but it’s not very flexible
when it comes to actually editing resources. The tool support in
Visual Studio is really quite inadequate to support localization
because VS doesn’t provide an easy way to cross reference resources
across multiple locales. And although ASP.NET’s design editor can help
with generating resources initially for all controls on a page – via
the Generate Local Resources Tool – it only works with data in the
default Invariant Culture Resx file.
Resx Resources are also static
– they are after all compiled into an assembly. If you want to make
changes to resources you will need to recompile to see those changes.
ASP.NET 2.0 introduces Global and Local Resources which can be stored
on the server and can be updated dynamically – the ASP.NET compiler
can actually compile them at runtime. However, if you use a
precompiled Web deployment model the resources still end up being
static and cannot be changed at runtime. So once you’re done with
compilation the resources are fixed.
Changing resources at runtime
may not seem like a big deal, but it can be quite handy during the
resource localization process. Wouldn’t it be nice if you could edit
resources at runtime, make a change and then actually see that change
in the UI immediately?
Using Database Resources
This brings me to storing resources in a
database. Databases are by nature more dynamic and you can make
changes to data in a database without having to recompile an
application. In addition, database data is more easily shared among
multiple developers and localizers so it’s easier to make changes to
resources in a team environment.
When you think about resource
editing it’s basically a data entry task – you need to look up
individual resource values, see all the different language variations
and then add and edit the values for each of the different locales.
While all of this could be done with the XML in the Resx files
directly it’s actually much easier to build a front end to a database
than XML files scattered all over the place. A database also gives you
much more flexibility to display the resource data in different views
and makes it easy to do things like batch updates and renames of keys
and values.
The good news is that the resource schemes in .NET are
not fixed and you can extend them. .NET and ASP.NET 2.0 allow you
create custom resource managers (core .NET runtime) and resource
providers (ASP.NET 2.0) to serve resources from anywhere including out
of a database.
As you perhaps know, default method (which is actually industry best practice) for Localizing .Net Applications is using resource files (.resx in this case). If you want to use database, you would have to write your own ResourceManager.
From this, the answer should be obvious: use standard and do not reinvent the wheel.
You might be wondering why Localization via resource files became industry-wide standard. Well, there are many reasons (too many to mention here), most of them regard to Localization process. The key one is, it is painfully hard to update (i.e. fix or install) translations for database driven Localization. Just think of what you need to install it - some SQL script. You know what will happen if you send out this for translation? Or even mistakenly update it? These kind of files are not very safe to work with (and they tend to be very large), so either you would need to create some kind of generator (with resource-like file as an input, which totally bits the purpose...) or you would need to be very careful (and pray that a translator won't break the file).
That is to say, database-driven Localization is sometimes the only sensible way of doing things - this is when you need to implement so-called dynamic Localization, that is allow users to translate things or add their contents in multiple languages.
For static Localization (typical scenario) use resource files.
Localizing user interface should not be stored in database, it is preferable to use the standard resx method because this will give you the flexibility to customize the user interface of front end for each client/deployment, without the need to change the back end or store much data about each client customization in database.
Regarding data (bi-lingual data or multi-lingual data) store them in database and use whatever technique suitable for the context (table per language, or duplicate columns for each language).
using resx is the best approach for some static values that needs not to be manipulated via UI of the app but if your values needs to be updated DB driven would be the best for it. For me its still a case to case basis. But one of the blogs I have seen in the internet made the resx files updateable via user interface.. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html.. hope this would help you.
As all the above are true, I want to add some additional insights.
I tend to use .resx based localisation, when working on "static" projects/websites like Dashboards or other small websites, which are focused on a specific usergroup.
When working on larger and more "dynamic" projects like shops, service-offerings, etc. (esp. when content is localized - not only labels) I like to use database localisation.
When you are developing on larger projects each language is maintained by another person, who is not necessarily in your project (especially in community-projects). Thus maintenance of different languages becomes a real hassle.
On the other side providing users some good/easy UI to update their language is time-consuming as well. So try to find a good path for your project.
my next assignments is to build 2 information portals for customers. These portals will be login protected sites and contain a set of pages displaying information like orders, invoices, pdf-files ... for the authenticated user (all presented as lists with links to detail pages). The users and the data are stored in an Oracle database. The portals differ in some of the features and in the layout.
My standard approach is to build an individual ASP.net Web Application for every portal.
But this is not the best way to get something reusable. So for these two projects my idea is to create a set of WCF services to get the Data from the Oracle database and to build user controls to display the different elements in Umbraco. This way I hope to get a set of independent, reusable “modules” which can be used to build these portals.
Now my question: is Umbraco a good platform for this type of projects? And is my “concept” a valid approach?
Kind regards
Volkmar
Umbracois very flexible. ON the one hand there is the question about security: With Umbraco you can use any Membership Provider you want for all visitors ( also with member roles).
On the other hand you have the question of the integration: With Umbraco you can create usercontrols, xslts or razor files as macros (which can be seen as the reusable modules).
For Xslt you can implement your own XsltExtension which pulls the external content as XPathNodeIterator you can use in every Xslt macro. For ascx files or razor you can use LinQ2Umbraco, your own objects etc to connect to the oracle database.
You also can use some sort of caching functionality to reduce the db-calls. On the other hand is one of the biggest advantages that Umbraco stores all the content as xml and object tree in memmory. So it is very fast in content rendering. With every database call you are loosing a little bit of this advantage.
hth, Thomas
Ruben Verbourgh began the Oracle4Umbraco project to create an abstracted fork for the Datalayer to support running on an Oracle DB. You can find it at http://oracle4umbraco.codeplex.com/, although it has no active releases, so build from source and YMMV.
Volkmar, your concept is perfectly sound - although you might want to consider using the Umbraco data store as the persistence layer for your data rather than in the Oracle DB itself. You get XML content versioning, caching, and all the benefits of the content-management side of things, in a robust and flexible framework which you can expose to other apps later should you so need to, through the Umbraco APIs and web services.
HTH,
Benjamin
content management of website becomes simplified with Umbraco.
But if you are planning to use Oracle as backend, Umbraco does not have support for it.
So decide carefully as to what parameters can be compromised.
Good luck.
Suppose that you have a big Data Entry Web Application Like Microsoft CRM, what is the strategies and technologies that you follow to build a website like it?
I don't want to use any Dynamic Web Page Generation software, because it have a lot of limitations..
Also I don't want to design every page and repeat everything
what's the best approach?
Any Ideas or Head lines on this issue?
Thanks in Advance...
Maybe you could try frameworks such as MVC or MVP. ASP.Net Development is leading to that direction.
You can read some introduction here:
http://www.asp.net/mVC/
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
This is a really general question and is hard to provide much guidance without some specific details. Is it an Enterprise App? How will it be deployed? Do you need to provide a Web Service Interface? What sort of back end data storage are you planning on using? What sort of authentication scheme do you need? And on and on .....
Here are some general guidance from the MS Patterns and Practices Team:
Microsoft Application Architecture Guide http://msdn.microsoft.com/en-us/library/dd673617.aspx
Microsoft Patterns and Practices Developer Home
You could create your own standard format xml file that defines the index fields you wish to key during data entry. Your web app would then read this xml file for whichever document/data entry forms you wish to be working with at the time. This will allow you to dynamically read and create a form based on the fields specified within your configuration xml file for multiple forms.
Your view / UI could render the configuration file and dynamically display the data entry fields as text boxes at run-time or you could use a scaffolding application like SubSonic to generate classes / forms for you and then alter the forms to include validation and custom scripts.
Are there solutions/tutorials/open source solutions to providing the functionality of having Content Editors edit ASP.net Localization files?
For example,
With Labels.resx and Labels.fr.resx, it would be great if theres an editor out there that allows End Users to end the content of the file.
I would suggest a database solution with caching. I found this article which might help. It has a complete provider along with a very good write up.
Creating a Data Driven ASP.NET Localization
Resource Provider and Editor
http://www.west-wind.com/presentations/wwDbResourceProvider/
ASP.NET 2.0 introduces a provider
model for creating custom Resource
Providers that can store localization
data in stores other than Resx files.
Resx resources are all fine and good
but putting data in a more flexible
resource store gives you many more
options for editing and administering
resources interactively and even at
runtime. In this article I'll
demonstrate how to create a new
Resource Provider that stores resource
information in a database and show a
resource editing tool that makes it
much easier to edit resources
interactively in the context of your
live ASP.NET applications.
Particular bit to note:
Resx Resources are also static – they
are after all compiled into an
assembly. If you want to make changes
to resources you will need to
recompile to see those changes.
ASP.NET 2.0 introduces Global and
Local Resources which can be stored on
the server and can be updated
dynamically – the ASP.NET compiler can
actually compile them at runtime.
However, if you use a precompiled Web
deployment model the resources still
end up being static and cannot be
changed at runtime. So once you’re
done with compilation the resources
are fixed.
I just wrote an application like that because I could not find a free soft that does resx editing:
Reads the content of all the resx files from a folder
Displays the values from different cultures but same resx besides each other
Generates/saves the resx files back
You might consider using structured XML files. Seems like this would be a more elegant solution than hacking .resx files to work in an unconventional way. You could use a LINQ query to get to the XML in a strongly typed manner similar to the resx file. Additionally, XML files could be edited by the user through the presentation layer since they aren't compiled into the application.