to begin with i18n using gettext, there are several proposals:
1. Create a new src/locale directory to keep the locale .po and .mo
files, which would be installed in $prefix/grass5 unchanged by 'make install'
.
We need to keep the .po files inside the grass dist directory to remove them
with rm -rf /usr/local/grass5 (which is brute).
2. Checks for gettext must be added to configure.in, and new include file
'glocale.h' should be something like:
On Tue, Feb 26, 2002 at 03:45:42PM +0100, Bernhard Reiter wrote:
On Tue, Feb 26, 2002 at 05:49:10PM +0300, Alex Shevlakov wrote:
> to begin with i18n using gettext, there are several proposals:
Shouldn't we delay this for grass5.1?
If alex likes to do it - why? As far as I foresee the
5.1 development, the modules are migrated piecewise into
the new repository. So it doesn't harm if done in
experimental environment.
We shouldn't stop anyone to improve GRASS in my opinion (we
even do not have enough people to program!). The examples
from Alex may rise interest of further 'advanced users'
to help with internationalization which is quite important.
In my opinion there will never come one particular day
when 5.1 will be started (it is already). We will have both
5.0 and 5.1 in parallel as 5.0 still lacks a sort of stable
2D vector engine. And 5.0 without vector modules does not make
sense to me.
On Tue, Feb 26, 2002 at 06:10:41PM +0100, Markus Neteler wrote:
On Tue, Feb 26, 2002 at 03:45:42PM +0100, Bernhard Reiter wrote:
> On Tue, Feb 26, 2002 at 05:49:10PM +0300, Alex Shevlakov wrote:
> > to begin with i18n using gettext, there are several proposals:
>
> Shouldn't we delay this for grass5.1?
If alex likes to do it - why? As far as I foresee the
5.1 development, the modules are migrated piecewise into
the new repository. So it doesn't harm if done in
experimental environment.
Sure I just wanted to make sure that he proposes it for the grass5.1 tree.
We shouldn't stop anyone to improve GRASS in my opinion (we
even do not have enough people to program!).
That is why we have the setting we have today.
We also should be strict about stableising GRASS 5.0.x.
We should aim for a data to add the new release branch
to the grass5.0 tree.
On Tue, Feb 26, 2002 at 06:24:33PM +0100, Bernhard Reiter wrote:
[...]
> We shouldn't stop anyone to improve GRASS in my opinion (we
> even do not have enough people to program!).
That is why we have the setting we have today.
mhhh - what's the conclusion ?
We also should be strict about stableising GRASS 5.0.x.
We should aim for a data to add the new release branch
to the grass5.0 tree.
Bernhard
In general yes - but there is a huge number of bugs in RT
which are open. However, before flooding 5.1 with code we
have to clean up the library mess. Then, on top of this we
can add modules (as some code from the modules must go into
libraries).
On Tue, Feb 26, 2002 at 06:34:33PM +0100, Markus Neteler wrote:
On Tue, Feb 26, 2002 at 06:24:33PM +0100, Bernhard Reiter wrote:
[...]
> > We shouldn't stop anyone to improve GRASS in my opinion (we
> > even do not have enough people to program!).
>
> That is why we have the setting we have today.
mhhh - what's the conclusion ?
This is an improvement which he should make in the grass5.1 tree.
> We also should be strict about stableising GRASS 5.0.x.
> We should aim for a data to add the new release branch
> to the grass5.0 tree.
>
> Bernhard
For the gras5.0 tree:
In general yes - but there is a huge number of bugs in RT
which are open.
We have to sort them into critical and non-critical categories.
Then we have a time where all bugs can be fixed.
We are in this time peroid right now.
Then we will branch, prerelease and hope to fix the critical bugs
on the release branch.
On Tue, Feb 26, 2002 at 06:56:05PM +0100, Bernhard Reiter wrote:
On Tue, Feb 26, 2002 at 06:34:33PM +0100, Markus Neteler wrote:
> On Tue, Feb 26, 2002 at 06:24:33PM +0100, Bernhard Reiter wrote:
> [...]
> > > We shouldn't stop anyone to improve GRASS in my opinion (we
> > > even do not have enough people to program!).
> >
> > That is why we have the setting we have today.
>
> mhhh - what's the conclusion ?
This is an improvement which he should make in the grass5.1 tree.
> > We also should be strict about stableising GRASS 5.0.x.
> > We should aim for a data to add the new release branch
> > to the grass5.0 tree.
> >
> > Bernhard
>
For the gras5.0 tree:
> In general yes - but there is a huge number of bugs in RT
> which are open.
We have to sort them into critical and non-critical categories.
Then we have a time where all bugs can be fixed.
We are in this time peroid right now.
Then we will branch, prerelease and hope to fix the critical bugs
on the release branch.
Bernhard,
this suggestion is not new. We have to *find* people to do it
(you are welcome of course).
As far as I see the current number of continous contributors I
even see problems to keep three trunks (5.0exp, 5.0release, 5.1exp).
We probably do not have the human resources at time to manage such a
huge code base like this. Up to now we didn't reach the number of
contributors as found for KDE or Linux kernel projects. Of course...
Anyway, the 'to branch or not to branch' has been discussed enough.
Point is that we obviously don't get fixed the 5.0 bugs in a reasonable
time frame. From that we have to draw conclusions about the threshold of
critical and non-critical bugs.
As far as I see the current number of continous contributors I
even see problems to keep three trunks (5.0exp, 5.0release, 5.1exp).
We probably do not have the human resources at time to manage such a
huge code base like this. Up to now we didn't reach the number of
contributors as found for KDE or Linux kernel projects. Of course...
Anyway, the 'to branch or not to branch' has been discussed enough.
Point is that we obviously don't get fixed the 5.0 bugs in a reasonable
time frame. From that we have to draw conclusions about the threshold of
critical and non-critical bugs.
One potential criterion for categorising bugs: was the bug present in
the release version of GRASS 4.3? If it was, then I can't see any
reason why it needs to delay the release of 5.0.
As for the RT, there appear to be a significant number of non-bugs and
maybe-or-maybe-not-bugs in there. If a bug isn't readily reproducible
from the information which is contained in the bug report, the chances
of anyone being able to fix it aren't good.
On Tue, Feb 26, 2002 at 08:07:59PM +0100, Markus Neteler wrote:
this suggestion is not new. We have to *find* people to do it
We just have to do it,
but this will slow down other developers somewhat.
But we have to keep the discipline so they are indeed encouraged to
help with this.
As far as I see the current number of continous contributors I
even see problems to keep three trunks (5.0exp, 5.0release, 5.1exp).
It will make it easier if we stick to this defined way
of keeping the source.
We probably do not have the human resources at time to manage such a
huge code base like this.
We can just make each step slowly.
Point is that we obviously don't get fixed the 5.0 bugs in a reasonable
time frame.
Then we remove all that unstable code.
If nobody cares to fix it or report the bugs then there is obviously
no interest in the modules.
Clearly PACKAGE may need to be defined in the individual Gmakefiles
(although it might be better to define it in a package-specific header
file, or even deduced at run-time from argv[0]), but LOCALEDIR should
be defined in config.h rather than in the Gmakefiles.
I'll change configure.in and src/include/config.h.in to define
LOCALEDIR automatically.
However, actually coding i18n support is usually less of an issue than
managing it. There needs to be some mechanism by which the message
catalogue maintainers are notified of changes to strings which have
localised variants.
On Thu, Feb 28, 2002 at 01:14:34PM +0000, Glynn Clements wrote:
[In response to the recent commits]
The references to LOCALEDIR should also be removed from the definition
of DEFS. C files which use LOCALEDIR should use '#include <config.h>'
to obtain the definition.
Also:
1. The calls to bindtextdomain() and textdomain() need to be
conditionalised upon the presence of libintl.h.
Yes, right. There must be ifdef. I'll commit the changes to two
modules soon.
2. Something should be including <locale.h> for setlocale().
It's included in libintl.h
3. I don't think that using LC_ALL is a good idea. E.g., this will
cause *printf() to use a comma as the decimal separator in some
locales. It should probably just be LC_MESSAGES.
I agree with that.
I've updated configure and config.h.in to define HAVE_LIBINTL_H, and
updated glocale.h to use it. I haven't changed anything in
g.select.pg/g.table.pg.
