[OPEN-ILS-DEV] Proposal: Versioned Add-on Packages

[Mike Rylander]

On Fri, Feb 20, 2009 at 1:46 PM, Dan Scott <denials at gmail.com> wrote:
> 2009/2/20 Mike Rylander <mrylander at gmail.com>:
>> In order to make extending Evergreen data structures as straight
>> forward as possible, we use an abstraction layer that has at its heart
>> an XML file called, by default, fm_IDL.xml.  This file describes the
>> structure of and relationship between objects that Evergreen's
>> component applications have access to, and tells the storage subsystem
>> how to get to the underlying data stored in Postgres.  All database
>> interaction is driven and directed by this file, and there are
>> explicit provisions built into this abstraction layer for the purpose
>> of extending the stock database schema with custom tables and views.
>> Local customizations can also be made to existing objects, extending
>> them in ways that allow local persistent fields to be added, and new
>> relationships to be described, all without changing any existing code
>> that uses these objects (with the exception of removing existing,
>> in-use fields -- that would be bad, m'kay?).
>
> <snip>
>
>> In order to integrate the content of these files into the main IDL, I
>> propose that we change the name of the stock IDL file to
>> fm_IDL_base.xml.  Then, we extend autogen.sh such that it takes the
>> content of each file in the extension directory and adds it under the
>> root node of fm_IDL_base.xml (taking care to avoid replacing entities
>> with their literal counterparts), generating an entirely new file
>> which will be placed at fm_IDL.xml.
>
> I'm thinking about the corresponding i18n process (of course!).
>
> For most purposes, the content inside the copy of fm_IDL.xml that
> lives in /openils/conf/ does not need to be translated. The exception
> is the reporting interface; we currently extract all of the
> reporter:label attribute values and generate an en-US POT file that
> can be translated into other languages. At build time, that POT file
> is turned into a DTD, and all of the reporter:label attributes are
> turned into corresponding entities in the copy of fm_IDL.xml that
> lives in the /openils/var/web/reports/ folder (and that file includes
> the DTD so that mod_xmlent can translate the reporter labels into the
> desired locale).
>
> I suppose the process doesn't have to change significantly. We could
> teach the reporter:label extraction script to parse all of the
> extension IDL files (it is a bit more complex if they end up living in
> the ILS-Contrib repository, but it can be done). We could generate one
> POT file per extension IDL file, then build the corresponding DTD
> files.  We would have to teach autogen.sh to create the entity-ized
> version of fm_IDL.xml in /openils/var/web/reports/ and to include each
> DTD file per extension that is included into the header of the
> entity-ized fm_IDL.xml. Teaching autogen.sh this trick might be the
> most time-consuming piece, as all of the I18N scripts are currently
> written in Python and involve packages that are only necessary for the
> release manager or translation mangler to have installed on their
> system.

I see two basic ways to deal with I18N that can keep the core-project
translators from having to deal with translating add-ons (which would
be on a different release schedule, most likely, and may not, in the
fullness of time, live in the contrib repo, if that ends up being
best):

1) Punt, and say that add-ons aren't translated, they just get strings
in their reporter labels (/me watches dbs pass out from sheer
exasperation)
2) Teach mod_xmlent how to load multiple DTDs, and in fact an entire
directory full of 'em, and provide a drop point add-ons to toss their
DTDs, making it the add-on developer's responsibility to supply
translation packages for Evergreen-supported locales.

With (2), add-on developers can copy and reuse the basic I18N
infrastructure from the core repository to start their translation
work, and their install scripts will just need to dump the DTDs (if
any) in place.

Eh?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com