Differences between revisions 5 and 6
Revision 5 as of 2007-04-25 09:07:38
Size: 3621
Editor: RhondaDVine
Comment: multilanguage and translation woes
Revision 6 as of 2007-04-28 01:46:58
Size: 4201
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
 * Release Management: (At least EzPublish has) an "invisible tree" attribute feature allowing release management.
 * Editorial workflow: (at least EzPublish has) a configurable workflow and multi profiles, allowing fine grained editorial workflow control and allowed edition areas.
 * WYSIWYG online editors: (at least EzPublish has) online wysiwyg editors, allowing fast contributions.
 * Object management: some CMS, (like EzPublish), leverage the concept of content objects, avoiding the hardlink or hardname traps.
Line 20: Line 24:
   * All CMS's (that I'm aware of) store content in a database, so this isn't an option. However Drupal (at least) has support for versioned pages within it's database.    * All CMS's (that I'm aware of) store content in a database, so this isn't an option. However Drupal and EzPublish (at least) have support for versioned pages within it's database. Ikiwiki uses a real RCS (cvs, svn, etc).
Line 28: Line 32:
 * Release Management: preparing new content that is not yet displayed, but can be easily activated by a simple switch in a central location.  * Release Management: preparing new content that is not yet displayed, but can be easily activated by a simple switch in a central location. 

A recurring topic on the lists is the suggestion that www.d.o should be based on a CMS. I thought I would try to summarise the argument a bit here. I'll also include some Drupal specific notes (my CMS of choice) - please feel free to add notes about other CMS's.

Pros

  • Easy maintainance of content by a large group of people who don't necessarily have a lot of knowledge about website maintenance, markup and CMS tools
    • While CMS's typically need at least one admin that knows the system, the vast majority of contributors only need to edit the content and CMS's are designed to make this easy. Most also provide optional WYSIWYG features.
    • By contrast WML markup is more flexible in that anyone can change the layout of any page without having to learn how a CMS works - new contributors do need to learn WML + maybe a couple of macro syntaxes and perl though :-)

    • (I'm rating this as a 'Pro' as I think ease of use trumps flexibility in this case, however YMMV) :-)

  • Allows for 'pretty' content for graphical browsers, without compromising viewability in text based browsers (lynx, (e)links, w3m), and screenreaders etc.
    • CMS's usually offer support for themes which can be selected on a per-user basis, so it is possible to have different themes tailored to different browser types.
  • Full text Searching
    • Weak point of current site, which relies on a fairly generic Google site search.
    • All CMS's (that I'm aware of) feature a full text search facility. Some offer more advanced searches. Also CMS's all allow categorisation of content - Drupal's 'taxonomy' feature is IMHO one of the most flexible.
  • Minimal client-side software requirements
    • Unlike with WML, there is no need for any client-side software to be installed except for a standard browser.
  • Release Management: (At least ?EzPublish has) an "invisible tree" attribute feature allowing release management.

  • Editorial workflow: (at least ?EzPublish has) a configurable workflow and multi profiles, allowing fine grained editorial workflow control and allowed edition areas.

  • WYSIWYG online editors: (at least ?EzPublish has) online wysiwyg editors, allowing fast contributions.

  • Object management: some CMS, (like ?EzPublish), leverage the concept of content objects, avoiding the hardlink or hardname traps.

Cons

  • Moving to a CMS is a massive job!

  • Pages cannot be versioned in CVS.
    • All CMS's (that I'm aware of) store content in a database, so this isn't an option. However Drupal and ?EzPublish (at least) have support for versioned pages within it's database. Ikiwiki uses a real RCS (cvs, svn, etc).

  • Multilanguage and Translation:
    • Most major CMS's have multilingual features. However, they don't support it well enough. I haven't yet stumbled upon a CMS that does content negotiation, so it is mostly a "translate all or nothing" roll (or a hard defined fallback to english).
    • Given the above Con about versioning, if the translators can't (easily) retreive the changes to the original of the page we most propably are going to lose lot of help, or translations at all.
  • Mirror sites would need LAMP stack.
    • This is a massive drawback as it limits who can mirror Debian. However little research has been done wrt whether the mirror sites are being heavily used - it's been suggested that the majority of users hit debian.org directly in any case.
  • Ability to include automatically generated content.
    • This is where CMS's are generally weak - it's usually necessary to directly modify the data in the underlying database to do this. Most major CMS's do have a plugin module framework which could be used to automate this kind of process.
  • Release Management: preparing new content that is not yet displayed, but can be easily activated by a simple switch in a central location.
    • Most CMS's allow for access control, so pages can be marked viewable only by the author. Not sure about the 'master switch' bit, but might be doable in SQL or as a plugin module.

Note: Some of the phrasing in this page is "hot off the lists". It could do with a bit of tidying up.

-- ?DavidClaughton