Silverlight localization of strings by resource files or?

What are the general advice on how to implement localization of a Silverlight application?

My first thought is that we've got a choice between resource files or storing the localization in resource tables in the database.

What are the pro's and con's for each method? Are there other met开发者_开发技巧hods?

Resource files would be render faster and reduce traffic as you wouldn't need to retrieve the strings from a webservice.

From a database it might be easier to maintain.

Let's say we would need to implement 3-4 different languages. What would be your choice, ..and why?

---

I know this will get a lot of traditional answers, but I would also like to put forward something completely original we tried (and succeeded) doing ourselves for more efficient localisation of Silverlight using Attached Properties instead of binding:

Link: Localisation of Silverlight projects after completion

We found resources and binding solutions to be tedious and not flexible as they all require the translations to be set in the project (and therefore needs a re-deploy of the app when it changed).

Traditionally translations are sent out in batches and managed by language (with unique keys, translator notes etc). (There are tools to make the conversion to resources easier, but we found a better way).

Our solution means we manage the localisation in a central server database but can also provide localisation editor, within the application itself, for translators to use while using the application.

Pros for resources:

• Simple to manage for small scale projects
• No extra code required

Cons for resource:

• They require a rebuild/re-deploy of the app for any simple language change
• The binding solutions about all have very long strings (which bloat the Xaml)
• The binding solutions add a huge notify overhead for items that seldom change (or rather only change all at once)
• Bloats SL download with unused languages

Pros for Database:

• Central repository for any number of languages
• Change language by downloading new data (max 200kb per language on large app)
• Only download language required and change on the fly
• Supports in-app editing of resources by translators (does require extra UI forms).

Cons for Database:

• Required more initial work to set-up
• Requires a database and matching service
• Requires a means of putting the translations into the right places (see above link for our solution)