.NET Localization != Multilingual
At least for US firms, the .NET story leads them down the garden path. They say, Oh great, I use resx's and, when I need to, I can advertise that my app works in multiple languages.
I remember when I first encountered the problem during the Beta2 days, I argued, dutifully, for using culture ID's (e.g., en-US) grabbed from the UI culture for choosing the phrases. I am glad that I lost the argument. As I've architected other applications for US companies, I've seen this issue come up every time. I've worked lately with Financial Services companies. Usually when they speak of internationalization, they really mean multilingual. They're crestfallen every time I explain they have to create a custom solution for the problem.
Now, if .NET would allow custom cultures such as es-US for Puerto Rico, for example, then we'd have no problems, though I think it would throw the current architecture out of whack, since it doesn't appear to be extensible at the AppDomain level that we're speaking of here. I'm not sure what the model should be, but there is a problem here. I know it is mostly a CLR issue, but this issue most consciously impacts the UI.
Summary:
- Multilingual != Localization
- There is a large need to support multilingual
- Perhaps, a need larger than for localization for US companies.