[opencms-dev] Support for multilingual content...? (Continued)
Laurent Gauthier
lgauthier at opnworks.com
Fri Nov 28 05:27:01 CET 2003
Sorry all but I was receiving list messages in digest mode and cannot
respond to the above thread so here is a continuation (see below for
original message).
Thanks to those who already responded with very useful insights and
comments and sorry once again for a long mail but it has substance (I
think).
I have given more thought to the matter of support for multilingual
content and did some investigations and tests with the OpenCMS core
code.
Here is what I managed to get working:
1) I implemented an I_CmsEventListener class called
FilesystemChangeListener that listens for a CmsEvent that gets fired
whenever a CmsResource is created.
2) I changed some core methods of CmsObject such as
CmsObject.writeFile(CmsFile file) so they fire a CmsEvent whenever they
succesfully modify a resource.
3) When a new CmsResource is created or changed, a CmsEvent is fired
with a type of EVENT_FILESYSTEM_CHANGE (I added this type to the core).
4) My "listener" class receives the affected CmsResource wrapped inside
the CmsEvent
5) The listener can then proceed to do nifty stuff such as walk the
resource tree and find similarly named resources in a locale specific
branch and flag them for change in the currrnt or another project. It
can also create a CmsTask and assign it the Translator group etc.
In other words, this is the cleanest way I can think of to attach some
kind of workflow to resources or to "automagically" find and flag
dependencies between resources based on business rules.
Now the problem is that we should really use the following method of
CmsResourceBroker or something equivalent to generate events otherwise
we may miss some changes and would have to insert event firing code in
umpteen methods.
/**
* This method is called, when a resource was changed. Currently it
counts the
* changes.
*/
protected void fileSystemChanged(boolean folderChanged) {
// count only the changes - do nothing else!
// in the future here will maybe a event-story be added
// TODO : OPNWORKS We would like to fire EVENT_FILESYSTEM_CHANGE
here but we
// don't have a handle on the CmsObject
// A_OpenCms.fireCmsEvent(new CmsEvent(this.getCms(),
//
I_CmsEventListener.EVENT_FILESYSTEM_CHANGE,
// Collections.singletonMap("resource",
resource)
// ));
m_fileSystemChanges++;
if(folderChanged){
m_fileSystemFolderChanges++;
}
}
As indicated in the comment, the problem I stumbled upon is that in the
CmsResourceBroker, we don't have any way to get to the CmsObject
instance or maybe I could'nt figure it out. Also, the resource is not
passed as an argument but since it is a protected method it should be an
easy refactoring. The existing comment actually mentions the opportunity
to insert event firing in this piece of code so this has been given
thought before obviously...
In any event, we need modifications to the core but at first look, it
doesn't appear too disruptive and would certainly open up a whole world
of possibilities...
If any of the caretakers of the OpenCMS core would like to comment on
this or give us an idea of the roadmap (if any) to have OpenCMS fire
events on resource changes, it could help us all.
Any other insights are welcome.
Laurent Gauthier
Mirasol Op'nWorks
www.opnworks.com
---------ORIGINAL MESSAGE -----------------
I have consulted previous threads on the need to support multilingual
resources (ex: to be able to create a page and specify its content for
different languages/locales) but no definite conclusion/direction seems
to emerge from these threads.
The current way to handle multilingual content appears to be to create
parallel folder trees for each desired language. However, this doesn't
allow explicit references between the various local-specific versions of
a given page. If one updates a page for one locale, the system cannot
"know" or "guess" that the corresponding page(s) in the other languages
need to be revised or updated.
One way to address this would be to have a resource (a CmsFile) contain
a Collection (Map?) of contents, one per desired locale.
When creating a page, you could specify which locales are to be
supported. When editing the page, you could switch between locales and
edit localized content for the file/resource. When viewing/previewing a
page, the system would display the content based on the locale in the
Session.
Some outstanding issues are things like: should it be possible to
localize metadata (keywords, description, title etc)?
Looking at the OpenCMS source and JavaDoc, it appears that this would
have far reaching implications and require substantial refactoring of
core classes and may also affect the way OpenCMS retrieves content from
the VFS (essentially, all content acccess would need to be Locale
sensitive). In other words, it may be quite disruptive to the system as
a whole.
Another way to address the requirement may be to have a special kind of
"Link" ressource type (a MultilingualLink). One that contains references
to locale-specific ressources. When creating/editing such a Link, one
would specify the desired Locales to be supported and possibly,
automatically create (if needed) files for each desired Locale in the
proper folders. When following a MultlingualLink the actual URL would be
based on the locale of the Session. I am not sure, at this point, how we
could/should manage and expose dependencies between target pages with
this approach (maybe with a special LinkEditor that supports editing the
Link targets...). Would it be possible/desirable for a "target"
page/resource to "signal" the link(s) that point to it that it has
changed and that other, localized versions of the same page need
revision?
My questions are thus the following:
- Do others agree there is a need to support multilingual content?
- Has anybody come up with a tentative design/solution that could
quickly and easily meet most of the requirements without too much
disruption?
- Is there a plan/roadmap to move towards support for multilingual
content in OpenCMS?
Feedback, comments, suggestions etc are welcome.
Laurent
More information about the opencms-dev
mailing list