 |
|
|
|
Marc,
I pointed out before that use case 2 is the main target scenario of current core implementation. Language specific pages should be able provide the same features as pages with localized settings and language specific module references - there are conceptual differences, the current core approach does not require additional tables, but does not enforce proper references in the database and has more challenges for getting implemented with same features (which has not been finished yet), that's why I am known to prefer a different solution. But in general, core content localization should be able to suit your needs and support use of multilingual modules as well. Unfortunately there are significant usability issues in this very first version, some options are hidden by the workflow implementation, which is mainly targeting our use case 3 and does not suit use case 2 - like you noticed, there is too much overhead for average users.
By concept, the current solution equally supports use of single language modules and multilingual modules (using multiple references to each localized page version) - there are still enhancements required, but besides we need to create motivation for developers to provide multi language support (which is mainly a requirement for use case 3), which will be needed for most of the modules with structured content like announcements, store, wiki, help, form and list, where localization needs to be done per item. Documentation should be the first step into this direction.
Forums is a special case, because I don't expect someone translating all posts. But in a multilingual site, there will be forums or groups in multiple languages, and while the list of forums in the current user's language will be the main request, pointing to additional forums in other languages might be helpful as well. For Example, on this site, if there are additional forums in many additional languages, they should get filtered for most English users, otherwise the forums list might become endless. However, there will never be the same number of forums and posts in Thai, Korean or Japanese, i.e. those users would need a link to the English forums, they might follow, if they are capable of the language (or trust in Google Translate). For a proper implementation, Chris will need as many as ML use cases from the community as possible - to create a valid solution for the majority of it.
|
| |
|
|
 | |
|
|
 |
Joined: 9/22/2006
Posts: 262
|
|
|
Thank you, Sebastian.
Your reply is much more sensible than the idea "It works under core-CL, so everybody should migrate to core CL now."
I often make the error of advocating a solution, where I only want to advocate a functionality. When I saw in the module settings of the forum under forum settings the option to indicate a forum group and a default forum, I thought that I had found a way to create localized forums. It did not work. But if this is to be the avenue to localize forums is not something I can say. As a matter of fact, I could think of a few better ways to arrive at the same effect.
Indeed, as I see it, each language would give access to a completely different forum with its own forum groups and forums. It would be up to the administrator to decide if he wants the same forum groups and forums or not. The scenario in which I see this as usefull: a student forum where students can exchange ideas on many topics would be in Khmer language. But our university receives each year a group of students from Korea and another one from Thailand. They receive a few lectures in English (the only common language), participate in "cultural exchange" (learning each other's folk songs and dances) and do a lot of socializing. If after the visit, students want to keep contact, the English version of the forum could be used.
In this scenario, I could effectively put both student forums on different pages, although having them on the same page, and changing from Khmer to English by clicking the country flag would be a nice touch. It would be the intuitive navigation path.
Yet, I am hypothizing about the future structure of the university porrtal, while it is still to soon in my strategic plan to make decisions on that level. Arriving at a cultural sensitive translation of the static resources is now the priority, thus increasing the ease of access for our Cambodian staff. After that comes staff training and after that input from the staff will decide the functions, the portal.should provide. I do not know if at that point, a forum in a multi-language setting will be required.
The whole process may easily take a year or more - managing change is not always easy. In that sense, having an idea of the direction in which a module will develop can be useful. If I know where you are moving to, I can better direct in what direction I have to move.
When I show you areas where I think DNN falls short, then the purpose thereof is to provide some input in future discussions. You have to run a ML site to understand its requirements. I can read from your answer that you have thought many of those aspects through, Sebastian, and I feel we agree on many aspects of the issue of internationalization and localization and that often you have better answers than I would have thought of. Thank you for sharing those.
Now, apart from all this, I have met in the module settings those two properties, forum group and default forum. The default forum, yes, but the forum group, I can see no scenario where that property is useful, taking into account that on separate pages you will have different forum groups and forums and on the same page - I don't realy understand what it is this property does.
____________________________________
The one-eyed in the land of the blind.
|
| |
|
|
| |
|
|
 |
Joined: 4/5/2003
Posts: 4377
|
|
|
I want to clarify a couple things here. I have never said to migrate anything here, nor was it ever my intent for you to do so. I really was, believe it or not, just trying to break down how the forum works today with the current core implementation. I went this route because your initial question read: "With the current efforts of dnn developers towards regionalization and localization, I would very much like to know if any changes are to be expected to accommodate content localization features." Now that I look back at this thread, with more posts, it is more clear to me that you are looking for a work around for your use case (despite the initial question I quoted, the rest kind of got lost after that). So, to explain the answer to your second question in that first post:
The purpose of the module setting for default group/forum is for use cases where there is a 'master forum', which we had on here in the past. This is a single forum module instance with all groups and forums (and now sub-forums) contained in a single moduleid. Then, you would copy the module instance to other pages and show only a specific group or forum on those other pages. To use this setting, you need to follow the instructions (for the help button on Forum Group in the module settings page) which state:
The forum group you would like to pull content from.
Tip 1
You must use the Add Existing Module from the control panel to pull content from the "parent" forum.
Tip 2
Selecting the aggregated group will automatically direct users to the aggregated thread view since only a single forum can possibly exist in that group.
NOTE
These settings are stored on a per page/module basis so even a copy of a module can have a different default group.
Now, in that same settings page just below that is a default forum treeview. You can then restrict the default view to a specific forum (this means, when going to page w/ module on it, people see a list of threads, not a list of forums or forum groups) with or without the group setting in use.
In the end, both of these properties do a very similar thing, they change the view a person sees when they initially view a page with the forum module on it. Who finds either of these useful? We have, in the past on this site used both of them.
|
| |
|
|
| |