Are there any good practices to follow when designing a model/ViewModel to represent data in an app that will view/edit that data in multiple languages? Our top-level class--let's call it Course--contains several collection properties, say Books and TopicsCovered, which each might have a collection property among its data.

For example, the data needs to represent course1.Books.First().Title in different languages, and course1.TopicsCovered.First().Name in different languages. We want a app that can edit any of the data for one given course in any of the available languages--as well as edit non-language-specific data, perhaps the Author of a Book (i.e. course1.Books.First().Author). We are having trouble figuring out how best to set up the model to enable binding in the XAML view.

For example, do we replace (in the single-language model) each String with a collection of LanguageSpecificString instances? So to get the author in the current language:

course1.Books.First().Author.Where(Function(a) a.Language = CurrentLanguage).SingleOrDefault

If we do that, we cannot easily bind to any value in one given language, only to the collection of language values such as in an ItemsControl.

<TextBox Text={Binding Author.???} />  <!-- no way to bind to the current language author -->

Do we replace the top-level Course class with a collection of language-specific Courses? So to get the author in the current language:

course1.GetLanguage(CurrentLanguage).Books.First.Author

If we do that, we can only easily work with one language at a time; we might want a view to show one language and let the user edit the other.

<TextBox Text={Binding Author} />  <!-- good -->
<TextBlock Text={Binding ??? } />  <!-- no way to bind to the other language author -->

Also, that has the disadvantage of not representing language-neutral data as such; every property (such as Author) would seem to be in multiple languages. Even non-string properties would be in multiple languages.

Is there an option in between those two? Is there another way that we aren't thinking of?

I realize this is somewhat vague, but it would seem to be a somewhat common problem to design for.

Note: This is not a question about providing a multilingual UI, but rather about actually editing multi-language data in a flexible way.