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 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 4:14 PM
 
donker wrote
 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 ...

Sorry, I overread this.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
9/5/2005 4:37 PM
 

I've proposed an option of core DNN modules localization under the thread "What ideas are floating around?". Would be glad to get your feedback on this.

Regards, Germans

 
New Post
9/5/2005 6:17 PM
 
donker wrote

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,

you stated in your first post, that you need a solution soon. So did other developers a couple of month ago and enhanced the core with the features they needed. Imho this is one of the basic principles of open source - to add functions and present the solutions. I am glad, ErikVB did this as I use his solution for our community service site DeutschNetNuke = DotNetNuke auf Deutsch, which would have been much more difficult without ML modules. I agree with you, that it would be preferable to have a core solution for content localization, this would have avoided the current situation with 3 framework localization solutions (from ErikVB, Locopon and Germans) and at least four approaches for ML modules (from same 3 and Bo)*. Fortunately the solutions of ErikVB, Locopon and Bo do not interfere, I use them in the same portal without problems, did not try Germans' yet. 

I am not happy with this situation though, as I would have preferred an earlier solution by the core team - or at least a concept for this as I demanded from the core team shortly after the first beta of DNN 3.0 came out in 2004. But now we have to shut the stable door, after the horse has bolted. We should take the time, to find the best solution for content localization, there are promising starting points, that have to be collected and formed into a concept, so we hopefully get fully ML done, soon after the move towards ASP 2.0 has been made. And I also expect, that the authors of the current ML solutions will jump on the train or at least provide an upgrade solution for their modules.

Sebastian

* Edit: forgot to mention Nokiko's ML solution for skin objects.


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
9/5/2005 7:14 PM
 

to sum up a little bit:

First we have distinguish between localization of dynamic framework components as page titles or module settings and localization of module contents. From the existing user demands I think, they should be realized with this priority order.

For missing framework localization there are approaches from various 3rd party developers, but a stable solution needs to be integrated into the DNN framework - adding translation options for page / module settings without complicating the user interface! Please keep also in mind, that some module specific settings might need localization as well. I see two general solutions:

  1. Adding translation tables, one for each of the settings tables, containing locale key, field name and translated values.
    Pro: easy to realise, same structure as original
    con: difficult for maintainance. Multiple tables.
  2. "donker" solution: adding a single translation table, containing locale, table name, field name and string value with a fallback mechnism to
    Pro: single table
    con: difficult to check for completeness.

These two approaches also apply for content localization:

  1. leaving ML as a task to the module developers - so only the search interface has to be enhanced in the core
    Pro: allows highest individuality for the module developers
  2. adding localizability to the framework as a central service for the developers with an easy interface
    Pro:
    1. ease of use could lead into broader support by more module developers
    2. allows for a central interface to translation services
    3. can lead to a consistent UI for import

      Con:

    1. does not fit into the decentral principles as for search, import/export,...
    2. how to realize user friendly input of ML content in the various modules?

Though the second alternative has the most pros - IMHO the second con is not easy to solve without deep restrictions for modules. If we are able to solve this, DNN will become a great ML framework.

Just my 2 cents.

Sebastian


Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
9/6/2005 3:48 AM
 

Sebastian,

Thanks for you contribution to this discussion. My frustration mostly concerns the attention it gets from the (mainly American) core team. When I met Shaun earlier this year I talked to him about this and hoped he would return to Canada knowing how important this issue is to us 'rest-of-the-world-citizens'. What we see are multiple solutions living side-by-side and that makes life more difficult. It is true that under the time pressure we have to make a move and implement whatever we have. I will add another solution to the growing stack of ML solutions and I'll publish it so anyone can comment on it/try it.

Peter

PS I notice that all localization packs are offered using the country code as well. This means that there are no 'generic language' packs. Shouldn't there be any? I mean, if a Flemish user (nl-BE) uses DNN, we only have 'nl-NL' to offer where probably it would have been nice to have 'nl' as well.


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 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