[Solved] How do you organize a localisation?

[Andrey]

Hello, All!

I have Resources.dll with localizable strings

Tey will translate to other languages.

And I have question.

Were I should store my strings?

e.g. I have an

1.[Persistent]
2.public class MyClass
3.{
4.  public string Name {get; set;}
5.}

And field Name - is a localization string "MyString1"

Should I write "MyString1" in DB? And what I should do when language will be changed? Maybe run-time perform Re-Fill neccasary fields (from Resources.dll to DB, which are contain localization strings?

Or I should write in DB some ID (or something else) and generate my localization string "MyString1" run-time?

Thanks.

[PetarP]

Hi Andrey,

 Unfortunately I believe I was not able to fully understand your goal. Do you want your translated strings to be stored or you require them only runtime? Can you please share some additional details regarding your scenario. 
We are looking forward to your reply.

Kind regards,
Petar
the Telerik team

[Andrey]

I have some initial data in my DB.

And user receives this DB with some filled data.

So it is my question.

What is better: Save strings in DB (initial e.g. in English language) and when user change language to Spanish - re-write all English strings to Spanish? All strings for all available languages are in Resources.dll

Or write to DB some IDs (or something else) instead real strings. And when user get each string - generate it from Resources.dll run-time for necessary language??

[IT-Als]

Hi Andrey,

Sorry for interfering your thread, but we had a similar discussion when we started the project I am working on right now.

After much talk, we ended up with the following:

- We use resources (actually satellite assemblies) only for static application strings. That is: error messages, labels, etc.
- For data the system creates (as part of a default installation) or the user creates we store it in the database.

The most important issue that prevented us from using resources and persistent objects in conjunction with each other was that when you do that, data is spread among something static (the resources) and something dynamic (the database . actually you will need to have resource keys register in a table row to "link" to the static resource).

We ended up creating a structure (of persistent classes) like this:

public class CultureStringSet
{
   private IList<CultureString> texts;
   ..
}

public class CultureString
{
  private string culture;
  private string text;
  ...
}

and usage:

public class CaseType
{
  // The owner (case type) holds the set and thus all localizations
  private CultureStringSet name;
  ....
}


We have helper methods on the CultureStringSet class to find the correct text, like GetText() for the current thread culture and GetText(cultureinfo) and GetText(cultureinfo, defaultcultureinfo)
We use a system default culture that the GetText methods fallback to if a text in the requested culture does not exist.

Doing the above makes it easy to add a new supported culture to the system, since you'll only need to traverse all instances CultureStringSet and add the new item in the Texts list for the new culture. All other classes (like CaseType) will have support for the new culture then.

Just my two pennies

Regards

Henrik

[PetarP]

Hello Andrey,

 I am writing just to check on how your project is going. Did Henrik's suggestions help? If not what other problems are you facing?
We are looking forward to your reply.

Best wishes,
Petar
the Telerik team

[Andrey]

Thanks Henrik.

Your propose seems very good.

I'll try to realize this concept in my project!

[IT-Als]

Hi Andrey,

Great if it works out for you.
If you have any questions regarding the design or so, please feel free to ask again.

Anyway, to help others that hit this thread by a search or so maybe I could ask you to please mark the question as answered if you feel it is so. Thanks.

/Henrik