>Viv,
>
>The thing I like about the DB resources is that you can do more with it. You can use them on the server as well as on the client - there's a handler there that can serve the resources from the DB as JSON scripts. And if you really wanted to it's pretty easy to create a routine to dump out the resources to disk entirely into static .js files as well. It'd be easy to automate and even keep in sync with the app when it starts using a small app-loader that rewrites the resources or an automated build task.

I can see the advantage of maintaining the ability to do some translation on the server - especially if client and server can use the same lookups. In my case it would make more sense to construct a resource file 'in reverse' - i.e.

(a) Annotate all strings needing translation in the HTML.
(b) Build the related gettext .pot file.
(c) Generate a .NET resource file from the .pot file

Haven't looked at how I might achieve (c) - but I see there's a System.Resources.ResXResourceWriter class.

>But I hear 'ya on this. I'm strugging right now between finding the balance of what goes on the server and what on the client. I have several apps that are client and there the decision is easy, but for some things (data obviously but for me also localization) the server still makes good sense and can make things easier than using pure static client side resources.

I'm off to the Highlands for a few days to see some field trials (and maybe get a bit of stalking) so it will be a good opportunity to mull it over (especially if I end up on Mull :-} )




>+++ Rick ---
>
>>Hi Rick,
>>
>>Thanks for the thoughts. I think I realize that the most efficient process would be to perform the translation on the server (and rely on caching to minimize how often this is done).
>>
>>But as mentioned 95% of the pages for this app are currently delivered as static HTML - all data is loaded via $resource calls to Web API and I don't fancy migrating them all to cshtml - and leaving them as is would make it much easier to migrate away from MVC if that became a requirement.
>>
>>In addition, this is very much a 'business' app so most of the pages are in fact just forms with the textual content limited to labels and error messages so I'm definitely leaning towards using angular alone to do the job. And since the text content is always short strings I also leaning to trying angular-gettext which, as I understand it, would only require adding the 'translate' attribute to the existing html where needed (and, of course, providing the lookup). I guess the downside is that the translation would occur every time the page is rendered so I'll keep an eye on the performance and if it looks like being a problem I'll also look at implementing the interceptor mentioned in the link.
>>
>>At the moment only Spanish needs to be added - but it came to dealing with 'right-to-left' layouts etc. I might be stuck if using this approach ?
>>
>>I'm going to take a look at your globalization toolkit anyway.
>>
>>Thanks again,
>>Viv
>>
>>
>>
>>>For most ASP.NET work I use a hybrid of client and server resources. I manage resources on the server and also publish them as client side resources (ie. publish the resx resources as JSON resources to the client).
>>>
>>>This works well for server rendered and server/client hybrid apps.
>>>
>>>For mostly client rendered apps (angular, ember etc.) though I'm considering just using JSON resources on the client which is easier.
>>>
>>>One advantage of the server rendered resources is that you can do nice stuff with resource providers including runtime translation as I doo with my West Wind Globalization toolkit:
>>>
>>>https://github.com/RickStrahl/Westwind.Globalization
>>>
>>>Makes managing and editing of resources much easier and includes the tools to serve resources in a variety of ways...
>>>
>>>
>>>+++ Rick ---
>>>
>>>>Hi,
>>>>
>>>>Don't know if this is the best forum but:
>>>>
>>>>I'm looking at the various options for hosting a multi-language web site and wonder what others are using.
>>>>
>>>>Seems like I have two basic options for doing the translation:
>>>>
>>>>(a) Server side with ASP.NET and resource files.
>>>>
>>>>(b) (Since I'm using angular anyway) Client side using angular-gettext, angular-translate or similar.
>>>>angular-gettext seems, on the face of it, simpler to implement.?
>>>>
>>>>
>>>>Client side appeals most since, at the moment, nearly all pages are delivered as static html.
>>>>Also a large part of the app is designed to work offline. Not likely that a user would want to switch languages whilst offline but client side translation would allow that.
>>>>
>>>>
>>>>As I side note - I read this : http://blog.altoros.com/speed-up-i18n-in-angularjs.html and saw an interesting line regarding latency:
>>>>"An additional 100ms delay led to Amazon’s sales to decrease by 1%"