In an early post I did make a rather non-commital statement about DNN should have used DSLocalizator and a module approach for their CL.  Let me just explain a bit more...

I do understand, like Sebastian has pointed out, that DNN must take into account all use cases, especially the top end (use case 3). 

My approach would have been to use the current CL as use case 1 fulfillment...ie. use the DSLocalizator module....make this DNN core module that can be loaded by all those that need only this level of CL....this would cover most community needs....and keep them happy!!

With use case 2 and 3, I would have started an new module (or 2), which could possibly be for professional and Enterprise only...hence keeping the community core the same and the professional, but giving the professional extra CL features, like the workflow and the need for large companies to cover international situations.....it's these companies that DNN needs and it's these that don;t mind paying the small cost (for them!!) of profressional DNN.

Some people might not agree with the idea of making Professional do the full CL and community having a cut down version, but in truth me and many member of the community have been running CL for many years, and although it's not always perfect and fustrating at times, it does nearly everything we need to do for our clients....plus if we find ourselfs in a need for more functionality, with my approach, that would be there waiting to help us fo those big client!!.

It's probably too late to make a U-Turn in devlopment now, so I think I'm committed to using the CL the DNN has implemented in future, but for now, it simply doesn't work!!

Regards,

Dave.

A project like DNN is always a question of compromising, a balancing act between ease of use, speed of generating a page and complication of the programming model. Any suggestions we make in this forum will be debated by the DNN team on their feasibility and the impact on the total project.

I have not (I think) critisized the page duplication solution. Much of the negative criticism in this forum results (in my opinion) from the fact that ML sites have already chosen a ML strategy and now want to see that strategy supported in core localization. My first reaction was the same, but as a user of the community version, I want my participation in this forum to be some way to pay back for the free software and free support I get from DNN and I cannot do that by looking only from my side of the project. I also realize that my comments should lead to better implementations for the Pro versions and having no experience with the Pro versions, my comments may not always be to their advantage.

I am currently preparing the process of moving my portals back to a hosted solution, and as that happens outside my job at the university, it may take till after the weekend. As long as that has not happened, I am unable to setup test situations (I have been promised access to the host server somewhere in the course of today).

My production site will have to continue using a third party localization solution for the forseeable future because of an unrelated problem ( http://www.dotnetnuke.com/Community/F... ). But once the transfer is finished, I will do tests on my local DNN configuration. Until then, I don't really know what I am talking about. On the other hand, now is the moment to speak up, now that the DNN teams are discussing further implementation. Ideas from the community may lead to a better implementation, while the community will also have to accept that some ideas can be considered unfeasible.

I called in another posting DNN 5.0.0 a public beta for ML sites. I still believe it was, but it was a good thing to release it because it started a dialogue about what ML sites want from Localization. I think DNN should rethink the way resources are managed through localizations. My solution for that may not have been the best one, but that's where I see shortcommings. Which Magick you use to remedy the shortcommings is up to you, but more Magick is certainly needed.

Sacha's point 2 was about modifying a one-language site into ML.I now understand the logic behind it. It does not explain how it works when you create new modules, when a site is already ML. How do you maintain ML on module level?

---

____________________________________
The one-eyed in the land of the blind.

From the little testing I've done on DNN5.5 I think you have got the option to use the default (base) module in all tabs.   But like you say, this doesn;t get over the fact that you have to create extra tabs, I don;t want to create extra tabs for each language...it's extra work that I shouldn't have to do...especially if the permissions are all screwed up, like they seem to be now.

As for support for older non-CL modules, this can be done without creatiing an extra tab. (Like DSlocalizatore does it, sorry to keep going back to it, but it's just a good example).  However I also have another method that I employ when a module can;t be used in a multiple langauge website.....I DON'T USE THE THING!!..maybe that should be passed onto some lazy devlopers out there that don't support multiple langauges.

Dave.