Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsLanguage PacksLanguage PacksWhat ideas are floating around?What ideas are floating around?
Previous
 
Next
New Post
9/8/2005 8:06 AM
 
Hi Sebastian,
I made some more analysis while I was waiting for approval of my last reply to your message and submitted an enhancement request to
Gimini, here is the link http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=1888 This solution is based on the use of ModuleSettings and TabModuleSettings tables, the only data type of SettingValue column should be changed to ntext to make it work.
 
Regards, Germans
 
New Post
9/9/2005 5:29 AM
 

Hello. I have one idea for a dynamic localization and I really would like to hear what you think about it.

Well the idea is pretty simple there should be added on table that will hold the translated values for the locales. These values can be Tab names, module names, module description, text content whatever you like. The key to link the localized information will be the ID of the tab or module, the type of the entity for which the localized value is stored and the type of the property that should be localized (such as name, description, etc.). So the table will look like this:

  • TranslationID (Identifier)
  • EntityID
  • EntityType
  • EntityColumn
  • Value
  • Locale

So let's say we have a module with name: "module1" and ID: 4.  In the translation table we add a record with the ID of the module (in EntityID), we set the type as Module (I have a Type table which holds all the types of entities), the EntityColumn is Name, Value will hold the localized value and locale the English locale ID.

In my application I decorate each property (of the Info class) that should be localized (such as name) with an attribute [Localize] and another showing the name of the column that holds the value. So when the dataprovider retrieves the information (e.g. ModuleInfo) it will check if there is attribute for localization if so it will get the information from the Module table but also from the Translation table. Because it has the ID of the entity, its type and for which column it needs the value it can be safelly retrieved. If there is no translated value it will use the value from the Module table (System-Default) if there is a translated value it will used the translated one.

This way I have only one table for translated strings that holds all the various types of translated properties in different locales.

 
New Post
9/9/2005 9:43 AM
 

ad 1) Sorry, but I don't get the clue of your concept on first sight

ad 2) I don't think, abusing oder enhancing the language editor would be best practice, as texts m be much larger and there is a synchon view of tables in two languages needed.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
9/9/2005 9:50 AM
 
germansr wrote
I made some more analysis while I was waiting for approval of my last reply to your message
Sorry, the last mail, I got from you, contained an invitation to review your localization solution. Due to the fact, that I have still some business and live besides DNN, this will take some time.
 
germansr wrote
submitted an enhancement request to Gimini, here is the link http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=1888 This solution is based on the use of ModuleSettings and TabModuleSettings tables, the only data type of SettingValue column should be changed to ntext to make it work.
Switching the data types to nText might be a good solution for other modules as well - we use this fields extensively.
 
Besides, I don't think, we should use this forum for an exclusive dialog just between us two, but invite all others to join the discussion.

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
9/11/2005 3:01 AM
 
mirror wrote

Hello. I have one idea for a dynamic localization and I really would like to hear what you think about it.

Well the idea is pretty simple there should be added on table that will hold the translated values for the locales. These values can be Tab names, module names, module description, text content whatever you like. The key to link the localized information will be the ID of the tab or module, the type of the entity for which the localized value is stored and the type of the property that should be localized (such as name, description, etc.). So the table will look like this:

  • TranslationID (Identifier)
  • EntityID
  • EntityType
  • EntityColumn
  • Value
  • Locale

So let's say we have a module with name: "module1" and ID: 4.  In the translation table we add a record with the ID of the module (in EntityID), we set the type as Module (I have a Type table which holds all the types of entities), the EntityColumn is Name, Value will hold the localized value and locale the English locale ID.

In my application I decorate each property (of the Info class) that should be localized (such as name) with an attribute [Localize] and another showing the name of the column that holds the value. So when the dataprovider retrieves the information (e.g. ModuleInfo) it will check if there is attribute for localization if so it will get the information from the Module table but also from the Translation table. Because it has the ID of the entity, its type and for which column it needs the value it can be safelly retrieved. If there is no translated value it will use the value from the Module table (System-Default) if there is a translated value it will used the translated one.

This way I have only one table for translated strings that holds all the various types of translated properties in different locales.

Mirror,

This is more or less the track that I'm on. You'll see a similar proposal a bit further up in the discussion. I'm currently testing this solution and it appears to work, believe it or not. I have successfully localized category names for instance in my Document Exchange with this method. I will wrap all of this up and post it on my site for further discussion.

Peter


Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsLanguage PacksLanguage PacksWhat ideas are floating around?What ideas are floating around?


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out