Thread: 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@gmx.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@gmx.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