 |
|
|
|
Marc (ម៉ាក) Vanhemelryck (វ៉ាន់ហេមិលរីក) wrote:
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?
Mark,
first please be aware that different use cases require different solutions - hence my previous separation of user cases. Language specific pages should be a valid approach for smaller sites with varying content per language. Other sites with their use cases may require different approaches - and according to my experiences with this community, they will be provided :) However, we need to make sure, there are proper interfaces for it provided in the platform.
This first implementation of localization has some nuts and bolds, which are important to be identified - before it gets used by a larger number of DNN sites and upgrade paths for existing ML solutions can be provided.
|
| |
|
|
 | |
|
|
|
bombar beest wrote:
I saw a couple of replies already that try to comfort people by saying "don't worry, you can still use module-localization if you want to".
Instead I would like to see: "don't worry if the module doesn't support localization, you can also use page-localization, but module-localization is the way to go".
There's a very important difference between the two. Module-localization should be -the- way to go forward, and page-localization should be an option, for unsupporting or older modules.
The way it is promoted now, is like "if you want localization, copy all the tabs", which isn't right at all.
Of course, many multi-language websites currently have different pages for different languages, but this is mainly because they lack the tools to do otherwise.
Bombar, I totally agree, there needs to be a motivation for developers of (advanced) modules to implement ML support. Most of those modules contain structured content (lists, hierarchies, clouds or whatever), which are edited (and need to be localized) item by item - and would require an appropriate interface for translation as well.
However, I agree with DNN Corp. that there will always be single language modules to be integrated as well (and this requires an appropriate solution for tab modules), and even most smaller sites will be able to live with monolingual modules only (if you have one announcement per quarter, you won't care).
|
| |
|
|
| |
|
|
|
David Lee wrote:
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.
Dave, regarding tabs per language, there are different aspects:
- from the users perspective, it should be easy to switch between different language of same page, like you do with MS KB. For users, it should always be obvious, which is the original version and which are manually or even automatically translated versions.
- an editor/admin wished to enter his text and provide a single link (regardless of the users preferred language)
- during localization of module and page properties, variation per language needs to be kept to a minimum! By default, every not doubtless language specific change should be applied to all versions (at least, after confirmation of the user). In mixed scenarios, there is a performance advantage in providing allproperties per language, even if edited for all/multiple of them, however this redundancy always bears the risk of inconsistency.
|
| |
|
|
| |
|
|
|
To summarize: there is now a first implementation to start with, within the next versions, there will be improvements to suit the needs of a number of users, but there will remain a number of use cases, which need to be covered by other solutions (instead of blowing up the core framework). It will be a major challenge for the team, community and developers, to define and provide appropriate hooks into the platform for proper integration of all these solutions.
|
| |
|
|
| |
|
|
 |
 |
www.nevoweb.com
Joined: 3/29/2005
Posts: 446
|
|
|
Thanks for your feedback Sebastian, your workload and commitment to the DNN cause certainly earns my full respect.
I don;t think anyone following this thread wishes to knock down the walls of the DNN fotress, having built my company on the back of DNN I really want DNN to improve and be a suscess.
Obviously people are going to disagree with the way CL is done by the DNN team...get 5 developers to solve 1 issue and you normally get 5 differnt ways of implementing it, all will probably work, but be bias towards each need and timescale. This is probably why devloping DNN is so difficult for the DNN team, they need to try and keep eveyone happy. They have done a great job so far and I do have every faith that CL will come out the other side working. But this is why I comment, because I do care!
I not complaining about the tab approach to CL, I just don;t think it's good at the moment. I think it needs options so that when a tab is copied/created to another language it doesn;t mean extra work for the people building websites day in day out.....what those options are, I'm not sure?
I also just feel a more baby step approach to this devlopment may have helped, the way to achieve this could have been a module approach, that wouldn't have broken the core.
Of course my comments are from a very external point of view, I haven't look at the problem as deep as yourself or the core team (In fact I've not looked at all, if I'm honest), so I am not going to start throwing stones from my glass tower!!
Regards,
Dave.
|
| |
|
|
| |