Peter's Example:
<msg key="dotlrn_main_portlet_pretty_name">Groups</msg>
(Group occurs in a few other messages such as "Join a Group" etc.)
My suggestion:
<msg key="dotlrn_main_portlet_pretty_name">Communities</msg>
(this would be one of the few places Communities would show up, because it is one of the few places where "classes" and "clubs" are listed in the same place. The " Join/Drop a Class or Community Group" link that can be found in this portlet would then read "Join/Drop a Class or Group"
Peter's Example:
<msg key="clubs_pretty_name">Community</msg>
My Suggestion:
<msg key="clubs_pretty_name">Group</msg>
This <msg key="class_instances_pretty_name">Class</msg> would not change.
Subject doesn't really belong in this discussion, because it is just a a way of grouping classes. The confusion in the UI comes from there being no way to add a class using the "Classes" link on the admin page (please feel free to try it here: http://dotlrn10-pg-test.dotlrn.collaboraid.net/dotlrn/admin/ ). In order to add a class we have to use the "Subjects" link.
I am not really sure why we should even limit Groups (or clubs if you will) from being associated with subjects or terms. Why shouldn't we be able to associate the "Group" Ancient History Club with the "Subject" Ancient History and the History "Department"? Why wouldn't we want to be able to limit the existence of a group (e.g. Students Against War in Iraq) to one term? What happens when we add Research Communities? They are usually associated with departments and subjects as well.
I do not want to unnecessarily complicate things here (sorry for going off on a tangent). One thing after another.
Sloan has a naming solution that works for their users and because there is a way to define "pretty_names" they do not need to change their way of naming groups, clubs, or communities. Openforce stuck to their guns with the "anything that is not a class is a club" concept, which makes naming them something else in the standard dotLRN install pretty simple.
In the long term we want to keep things simple. We need to think about what kind of communities we are going to be adding to dotLRN in the future and how we can keep confusion to a minimum in the process.
I am not interested in turning everything on its head, but I am very interested in consistency in the standard install before 1.0 goes out the door. We need to decide which way we want to go on this: replacing "Subgroups" within "Communities" with "Sub-communities" or replacing references to "Communities" with "Groups" (and vice versa). The longer we wait on this the more the confusion an inconsistency trickles into the translations that we all have been working on for the last couple of weeks.