I was thinking about organizing the translation files in a more efficient
manner. (not for 8.0, obviously)
Right now we have one PO file for each combination of program (or library) and
language. The idea was that one only has to install the translation files
for the PostgreSQL pieces that one actually uses on a particular system, and
this is basically how it has worked out.
Nevertheless, I think it may make sense to provide only a single PO file for
each language, covering the entire PostgreSQL source tree. Because if you
think about it, the above space-saving scheme actually wastes space. If you
install a PostgreSQL server package today, you install 14 translations, 93%
of which you don't need. On the other hand, if we only provided one PO file
per language and encouraged packagers to create a separate package for each
language (say, postgresql-i18n-de), then a client-only installation wastes
more like 60%, and a server installation (which usually includes the clients)
wastes nothing. Moreover, English speakers have the option to install no
translations at all.
Now, the above can be accomplished by realigning the packaging without
changing the PO files, but if we were to do that, then there is little reason
to keep separate files. Moreover, having one big file would have several
other advantages: It would save space because many strings are duplicated in
several PO files. It would make life easier on those installing the
translations. I suspect it would also make life easier for translators. And
it would be easier to release translation updates or new translations between
code releases. And it would easily solve issues like translatable strings
appearing in the pgport library, which has no makefile structure to support
translations (which would be a waste for like 5 strings), and no run-time
support either.
Comments?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/