

Why Internationalization is Hopelessly Broken in ASP.NET - jasonkester
http://www.expatsoftware.com/articles/2010/03/why-internationalization-is-hopelessly.html

======
CWuestefeld
It seems that the OP hasn't noticed that Resource Provider is an, ummm,
_Provider_. With that pattern, MS supplies a default implementation, but
you're free to build your own.

Our web site uses a custom Resource Provider, allowing us to store all the
translations into a database. And the key to getting the resources back out
isn't just the user's language, but also the Customer's identity, so that all
the text in the site is completely customizable per customer.

The end result is something that's probably easier to maintain than the
"Everybody Else" that the OP references.

Oh, and under "Referencing Translated Text (by using)", I don't get the
complaint. You can name your resource anything you want, so it can be just the
same as "The text itself" if you want. But in rich, complex systems it's
frequently not safe to leave it as such. The text is also dependent on the
context in which it's displayed, so two places on your site that have the same
text in English may translate as different strings once you factor in the
contextual stuff.

~~~
jasonkester
Actually, storage is the least problematic part of the default i18n scheme in
ASP.NET. It'd be just as easy to dump out .resx files from FairlyLocal instead
of .po files.

The thing that needs fixing is how you mark text for translation, since that's
the thing that developers won't do if it's painful. In the "Everyone Else"
world, you get in the habit of writing _("") everywhere you'd normally write
"", and suddenly all your text gets translated automatically.

It's pretty cool.

