[Pmwiki-users] internationalization & flexlayout

[Patrick R. Michaud]

On Mon, Aug 11, 2003 at 11:40:55AM +0200, Carlo Strozzi wrote:
> [...] The current customization scheme of pmwiki, that is
> overriding sections of actual code to attain a customized behaviour,
> has significant drawbacks, as it inevitably causes local extensions
> to interfere with each other. For instance I need to load flexlayout
> *before* I load "printable-page", and things like that. 

Agreed.  But this is a common problem in many development efforts--even
closed source ones.  At the leading edges of development there are 
conflicts between new features and modules, but eventually the 
conflicts are worked out as the modules mature and they eventually 
migrate into the core system.  Flexlayout.php is a perfect example--
in its original form it was English-only, and it needed some updating 
to coexist with the i18n efforts that came later.

Many modules have gone from being local customizations to core modules--
these include WikiTrails, session-based authentication, attachments/uploads,
the RSS scripts, etc.  This generally happens when the module reaches
a level of maturity where I think it can be safely maintained and
functional with the other core modules that exist.  My goal is that
someone should always be able to download the core PmWiki distribution 
and know that it's internally consistent and workable.  The Cookbook is 
intended to be a central repository of contributions, extensions, and 
tips from PmWiki users and developers.  By its nature, the things
in the Cookbook (leading edge and specialized features) may not always 
be completely compatible with each other.

> Orderly customization requires that local data be kept in files
> separated from the code, or otherwise establish a better interface for
> plug-in's. In this respect pmwiki does have problems.

We could potentially design a system interface in which conflicts occur 
less often between newly developed modules, but I fear that the price 
of having such an interface will be a much steeper learning curve for 
a new developer that is thinking about creating a new customization.
I think one of the advantages of the current system is that the 
customization process is fairly simple, so people can look at them as 
starting points for new customizations.  Yes, this may lead to some
conflicts, but in my experience it has not been *that* difficult to
resolve the conflicts as they're identified.  Sometimes conflict
resolution is less costly than conflict avoidance.

Also, just so people know, my expectation is that PreviewEdits and maybe
Internationalizations will be the next modules to migrate into the
core PmWiki distribution.  I'm also looking at incorporating John Rankin's 
PrintablePage modules, since they seem to be very popular among PmWiki 
sites.

>From a PmWiki development perspective it would be very helpful to me if we
could establish a way to know which desirable and upcoming features
are in highest demand.  There has been some preliminary discussion of 
this at http://www.pmichaud.com/wiki/Development/DevelopmentPriority
but nothing has come of it yet.

Pm