At 08:06 AM 5/31/2006 -0700, John Anderson wrote:
We explored various implementation approaches, most notably the following two:
As the Python eggs are discovered during Chandler launch, those that
contain mo files that have not been copied to the mo installation
directory will be copied. So that after Chandler has been started once
all the mo files are installed. In the long run, when the repository is
built as part of the build process, our customer would never incur the
overhead of the step, unless they installed new language eggs, and then
only once.
The second approach is very similar, except that rather than copying files
to an installation directory, a dictionary is setup in the repository
during parcel installation that maps locale to a list of paths to each mo
file the eggs or some other convenient data structure for runtime lookups.
The first approach has the advantage of potentially working with Python
projects other than Chandler and the gettext mechanism is designed to work
with mo files stored in a directory. It has the disadvantage of storing
two copies of the translation files, and when used by developers who
regularly create their repository from scratch the translation files might
not be available before the first string needs to be localized.
Note that that would only occur if the translation files were deleted along
with the repository (which we could simply not do), or on the very first
installation. So it's not likely to be a significant disadvantage.
The second approach has the advantage of being simpler to implement since
we can use the existing parcel install mechanism instead of building a
similar mechanism for eggs.
Actually, both approaches would use an identical API for the developer;
whether that API copies the files or registers them in the repository is
purely an implementation detail. In both cases, the installParcel() hook
provides an opportunity to invoke the API to register (or copy) the resources.
We could actually use one approach initially, and then decide to switch to
a different one later, and nobody's code would change.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
