Re: Reorganization of the translation files

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/

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I was thinking about organizing the translation files in a more efficient
> manner. (not for 8.0, obviously)
> [snip]
> 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.

Sounds like a win to me on that grounds alone; but probably the
translators need to have the biggest say here, since they'll be affected
the most.

One question is whether the gettext code is markedly less efficient when
accessing a large .mo file than a small one; if so, the consolidation
would probably hurt client performance.

regards, tom lane

On Tue, Nov 09, 2004 at 12:00:46PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > I was thinking about organizing the translation files in a more efficient
> > manner. (not for 8.0, obviously)
> > [snip]
> > 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.
>
> Sounds like a win to me on that grounds alone; but probably the
> translators need to have the biggest say here, since they'll be affected
> the most.

The biggest downside I see is the long execution time for msgmerge.
I can live with that, especially if it will save me translating "out of
memory" six or seven times.

The other downside is that the cool status table will be reduced to one
line. I can live with that too ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"La tristeza es un muro entre dos jardines" (Khalil Gibran)

Alvaro Herrera wrote:
>
> The biggest downside I see is the long execution time for msgmerge.
> I can live with that, especially if it will save me translating "out of
> memory" six or seven times.

I'm using poedit which can replace empty translations with previous
translated values for the same/similar strings. This can save you some
time when translating common errors and command-line options;
unfotunately, importing strings from other projects (kde, gnome, ...)
doesn't help much. :(

Regards,
Aleksander

I'm not sure about other translators, but I'd like to see two files: one
for the backend and one for the utilities.

Translating strings can be a slow and tedious process and completing
them all at the same time is not likely. With two files you can choose
to translate the tools during one development cycle and the backend
during the next one, while keeping some overview over your progress at
the same time.

Regards,
Aleksander