Jan Olsmar wrote:

Thanks for a good post Sebastian.

I think we all know that to implement content localization is not an easy task. DNN Corp. have chosen a path, maybe not the path I should have chosen but every solution has its pro and con’s.

My concern is not the path more is DNN Corp able to deliver a working solution for this.

Why should I have concern about this they have proven they can deliver for years?

Yea that true but during the years a lot of bugs in the area localization have discovered without the attention that I had expected from the DNN Corp. My feeling has been that those bugs are not so important because it works for the most users anyhow.

As a result of a DNN fork back in the start of this century static localization was delivered and content localization was promised.  Now 2010 we have got the first release that implement content localization as well. That’s nice very nice.

But…..It does not work.

 OK to be honest it works if your expectations are very low. I didn’t expect a bug free and in all parts mature solution.  I must say that in some parts it works much over my expectation.

But.. It does not work.

I spend less than an hour testing the new release and found in my opinion bugs/breaking changes that make the release impossible to use and in some case if you don’t use the content localization feature it breaks your urls for your site as well.

Ok I looked for information to see if this was mention in the announcement but not a world. I could understand if new features like this could have done this.

OK I put my issues to Gemini and had to spend some time to explain the issues there. For me it was so obvious that no further information was needed. Still today they request more information.

So this is my concern. We have a Product department, design department, development department and a Test department.  To get the product to work in a multi-language world all these departments needs to understand the problems. This department needs also have the skill to in a professional way deliver specification to their receiving department.

 Furthermore needs the management understand the problems so right people take the right decisions.

In my opinion the release 5.5 was released in a shape that just harmed a good product. If this was made depending on the lack of knowledge in one or more of the “departments” above or bad management I don’t know but I am rather sure this had not happened in Europe.

I hope I am totally wrong and a release 5.5.1 is fast delivered solving the issues, a junior tester should have found, and after that a release 5.6 that takes the implementation one step further.

While a good idea is to inform the community how the solution is designed so other module developer can change their products accordingly.

David Lee wrote:

 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.

cathal connolly wrote:
2. Sacha was asking about the difference from "clone" modules. The changes we made for localization add support to track the translation status of content e.g. if i add some en-us content, add a language (e.g. de-de) and localize the site the existing modules are effectively cloned (using the existing tabmodules support). However some additional values are written so that the relationship with the original content is maintained. This is important, as it allows us to see that the new content (de-de) is not translated. To translate the content the user detaches the module, this means that the 2 instances no longer share the same piece of content, instead it's copied to the new one. The user can the translate it and mark it as translated. Despite the fact that the tabmodules relationship is gone (due to the detach) the values allow us to track the relatioship and translation status. Finally, creating the module instances in this fashion allows us to add additional fuctionality e.g. we create language specific translator roles and apply those permissions as part of the process.