Here's a proposal from Richard R and myself about how to manage and
distribute language packs (for now, Messages_xx.properties files).
Right now some are on the patch queue on SF and some are on a Wiki page,
we really need a better way. Managing and distribution are discussed
We feel that it's best not to distribute all of the language packs with
the main DSpace download for these reasons:
* The translations for all languages might not be available in
time for the main 1.x release. We wouldn't want to have to wait for all
translations to become available before doing a release. It would be
nicer to be able to distribute new translations separately as they
* If people localise their site, they might not necessarily be
able to also localise the translations. For this reason they might not
want to have all the translations installed on their site. Given that
people might not realise this at first, and be inadvertently serving
non-localised content, we think adding translations should be 'opt in'
rather than 'opt out'.
So, the translations should be separate downloads. We thought of two
* Individual downloads, presented as a grid of DSpace version x
language (not necessarily fully populated, but gradually filled out over
time), as shown below. Main problem is, we don't have a decent place to
put up and manage this grid (SF won't let us do it, the Wiki would just
about work, don't want to add to dspace.org maintenance load).
* Language pack downloads from SourceForge, to be updated whenever
a new language is translated. e.g.:
dspace-languages-1.3.2-1 (contains fr, zh)
dspace-languages-1.3.2-2 (contains fr, zh, pt)
dspace-languages-1.4.x-1 (contains zh)
dspace-languages-1.4.x-1 (contains zh, fr, pt)
and so forth. This lets us leverage all the monitoring tools etc. of
SourceForge, and is clearly visible to people downloading DSpace because
it's in the same place as the main donwload. People can download this
and drop the languages they want into their DSpace instance (or the lot
if they haven't localised their UI).
Richard & I favour the latter approach.
We propose creating a separate CVS module to manage the language packs.
We considered putting them alongside
config/language-packs/Messages.properties in the main dspace module,
* This means when we're tagging a release in CVS, not fully
translated packs would get tagged inappropriately (or we'd have to
resort to script hackery).
* Given the files are distributed separately, the
make-release-package script would need to take them out anyway.
The language files in this module would be tagged with the same tag as
the main DSpace release when they're complete. As with the code, the
SourceForge patch queue would become the standard means of contributing
and tracking updates (as opposed to a buried Wiki page).
Unless there are objections to this approach, I'll create a module
called 'language-packs' in CVS and start loading up the translations we
have from various sources (currently patch queue + Wiki page).
Robert TANSLEY / HP Labs / MIT Visiting Researcher