Products

Evoq Content Overview Content Creation Workflow Asset Management Mobile Responsive Personalization Content Analytics SEO Integrations Security Website PerformanceEvoq Engage Overview Community Management  Dashboard  Analytics  Member Profile Gamification Advocate Marketing Community Engagement  Ideas  Answers  Discussions  Groups  Wikis  Events Mobile ReadyDNN Support PackagesEvoq: CMS FeaturesEvoq OnDemandCompare DNN's CMS Products

Solutions

Content Management SystemMulti-Channel PublishingDigital MarketingOnline Community ManagementIntranet Software SolutionOur CustomersPrime

Resources

Test DrivesSchedule A DemoDocumentation CenterWebinarsWhite PapersProduct ManualsRequest PricingData SheetsCase StudiesEvoq Preferred Products Content Management Ecommerce Forms Identity Management and Authentication Site Management Social Themes

Partners

DNN Partners Partner Directory Become a DNN Partner Partner Program Overview  Hosting  Implementation  ISV  Training  Competencies

Community

Participate Ask a Question Forums Community Showcase DNN MVP  Program Overview  Lifetime MVPs  Honorary MVPs Subscribe to DNN Digest Advisory Groups  Awareness Advisory Group  Developer Advisory Group  Partner Advisory Group  Technology Advisory GroupLearn Documentation Wiki Community Blog Video Library Project History Development RoadmapDownload DNN Store Language Packs Manuals Nightly BuildsSecurity Policies Security Center

Blog

About

News Press Releases News Coverage Press KitCareersContact DNN

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 PacksTrying to forge ahead: making the case for a dynamic localization solutionTrying to forge ahead: making the case for a dynamic localization solution
Previous
 
Next
New Post
9/5/2005 12:10 PM
 
Peter Donker


Peter Donker's Avatar

Peter Donker's Avatar

Peter Donker's Avatar

www.bring2mind.net
Joined: 12/1/2003
Posts: 714
leupold wrote

Peter,

as fas as I know, there is no concept published by the core team, that covers content localization, Vicenc should know about the status. But I fear, they will not decide soon about the method to be chosen.

Currently there is an solution existing from ErikVB, that contains an API, you may contact him, maybe that is an option for you.

Sebastian,

I will not even consider proprietary solutions. I am very upset by the fact that I have clients that will be stuck once the core finally starts implementing ML because they're building on none core additions. It is just very unfortunate that Erik decided to move ahead and throw this in the market, although I can see that the core team has been much much too late to move on this issue and still does not move.

Peter

Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
New Post
9/5/2005 12:11 PM
 
Peter Donker


Peter Donker's Avatar

Peter Donker's Avatar

Peter Donker's Avatar

www.bring2mind.net
Joined: 12/1/2003
Posts: 714
leupold wrote

Your solution sounds advanced with options to support translation services as well, but how do you handle ML HTML/Text, that use nText instead of nVarChar for content and summary - handle this in a separate table? Reduction to a single interface would be preferable - my opinion.

That's why I proposed ntext ...

Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
New Post
9/5/2005 12:19 PM
 
Peter Donker


Peter Donker's Avatar

Peter Donker's Avatar

Peter Donker's Avatar

www.bring2mind.net
Joined: 12/1/2003
Posts: 714
ErikVB wrote
Peter,
 
The method i use to get localized text from the db is much like your suggestion. In one call (just passing the current locale), i get alternative texts in this order: portal locale, system default, any text. iow if text for the requested locale is unavailable, text in the portal locale is returned, and if that is not avaible, text in the system default, and if that is not available then just any available text...
 
To be exact, the api i have available is for navigational localization, not for content localization as such.
 
My suggestion to the dynamic localization of module content would be that module developers implement the actual localization themselves (its not very hard to do), but that an "ILocalizable" interface would be available in the core, by which modules can communicate their localization features to the core. This will be usefull for displaying in one spot what modules offer dynamic localization, and what content is localized in which locales.
 
Apart from this, the search procedures should be slightly changed, so we can pass a locale to addsearchitem. The search module should always only search in the current locale, but an advanced search module should be able to search in a specific locale or in all locales.
 
cheers,
 
erik

I'm looking to kick off content localization. And I believe the goal set out by the core team has been to come up with a generic solution. My criticism of current methodologies is that they rely on too many tables and are not really core implemented. What we should aim for is a similar feature as GetString which is very generic. That is why I launched this appeal.

Peter

Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
New Post
9/5/2005 12:30 PM
 
Erik van Ballegoij


Erik van Ballegoij's Avatar

erikvanballegoij.com
Joined: 4/7/2004
Posts: 4445
donker wrote

I'm looking to kick off content localization. And I believe the goal set out by the core team has been to come up with a generic solution. My criticism of current methodologies is that they rely on too many tables and are not really core implemented. What we should aim for is a similar feature as GetString which is very generic. That is why I launched this appeal.

Peter

 
I'm not quite sure if i follow you. If you are developing a custom module, you are responsible as to how the data is stored in the db. If you want to be able to localize your content, you will have to write the logic to do so. I agree with you that too many tables are necessary, but i cannot see how you would want to do it with less tables....
 
The getstring function can be generic because it is known upfront what data will be localized, what type of keys will be used etc. I doubt this same kind of generic solution can be applied to dynamic content. I don't want to just localized ntext, but also other types of data.
 
In my opinion, no core change is needed in order to be able to localize module content. The core changes i think are necessary are in the area of tab localization, module title localization and such.
 
cheers,
 
erik
Erik van Ballegoij, Former DNN Corp. Employee and DNN Expert

DNN Blog | Twitter: @erikvb | LinkedIn: Erik van Ballegoij on LinkedIn
 
New Post
9/5/2005 12:49 PM
 
Peter Donker


Peter Donker's Avatar

Peter Donker's Avatar

Peter Donker's Avatar

www.bring2mind.net
Joined: 12/1/2003
Posts: 714
ErikVB wrote

 

 
I'm not quite sure if i follow you. If you are developing a custom module, you are responsible as to how the data is stored in the db. If you want to be able to localize your content, you will have to write the logic to do so. I agree with you that too many tables are necessary, but i cannot see how you would want to do it with less tables....
 
The getstring function can be generic because it is known upfront what data will be localized, what type of keys will be used etc. I doubt this same kind of generic solution can be applied to dynamic content. I don't want to just localized ntext, but also other types of data.
 
In my opinion, no core change is needed in order to be able to localize module content. The core changes i think are necessary are in the area of tab localization, module title localization and such.
 

Maybe I need to write out the proposal. What you'd be responsible for is the management of the string IDs within your module, just like you are now. But the storage is outside of your module. I'll write it all out if I find the time.

Peter

Peter Donker
Bring2mind http://www.bring2mind.net
Home of the Document Exchange,
the professional document management solution for DNN
 
 Page 2 of 4
Previous1234Next 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Provider and Extension ForumsProvider and Extension ForumsLanguage PacksLanguage PacksTrying to forge ahead: making the case for a dynamic localization solutionTrying to forge ahead: making the case for a dynamic localization solution


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