[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Re: internationalization files layout

From: strk
Subject: Re: [Gnash-dev] Re: internationalization files layout
Date: Fri, 24 Oct 2008 10:05:08 +0200

On Thu, Oct 23, 2008 at 07:48:46PM -0700, John Gilmore wrote:
> Sorry for the slow response...
> > My proposal is as follows:
> > 
> > 1) Don't distribute .gmo files.
> How will end users get translated messages, then?

End users get a binary package, which should include them.
End users which are also builders will generate .gmo files
from the .po files, getting a WARNING on ./configure if they

> > 2) Don't install .gmo files if gettext isn't found.
> I'm not sure what you mean, "if gettext isn't found".  Found on the build
> system?  Found on the target system that installs a binary package?

Found on the build system. This simply means: don't try to install
something you don't have (as if gettext isn't found, gmo aren't created).

> I think we pretty much have to assume that every installation is
> internationalized.  The English-speaking population of Linux users
> is a small fraction of the total users.

The binary packages should always have up-to-date .gmo files.

> > 3) Don't update .po files on 'make dist'.
> I was following the gettext manual:

That page talks about invoking 'autopoint' (funny name, yes, but it
means auto PO internationalization...). We are not doing this.

>   In projects that use GNU automake, the usual commands for creating a
>   distribution tarball, 'make dist' or 'make distcheck', automatically
>   update the PO files as needed.

We were doing this manually in po/, but I didn't like
the automatic update of source tree on 'distcheck'. We may want
to change this back if it's really that standard.

>   If GNU automake is not used, the maintainer needs to perform this
>   update before making a release:
>      $ ./configure
>      $ (cd po; make update-po)
>      $ make distclean
> > 4) Keep the update-po rule to explicitly update gnash.pot and .po files,
> >    to be used periodically with a subsequent commit.

We do have this. 

> The big issue is when to update gnash.pot.  It gets the messages from
> the actual source code.  Then the .po files get merged with the updated
> gnash.pot.  It is clear that this has to happen during the release process --
> probably several times during the release process.  (Once before you
> get the translation teams fired up to do their updates for the upcoming
> release; once before the final release, to pick up any changes in 
> messages in the source code; and at any other times that improve your
> ability to provide translations.)  Yes, each time, there should be
> a subsequent source-control commit of the altered files.

Yes, this has to be written down somewhere. We used to have an HOWTO_RELEASE
file in repository for other projects. I think Russ is using a wiki page


reply via email to

[Prev in Thread] Current Thread [Next in Thread]