This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Free Translation Project
* Martin v. Loewis (martin@loewis.home.cs.tu-berlin.de) [20000508 00:11]:
> Is it really necessary that gcc.pot is always up-to-date?
Not really, at least not if gettext is used as it will match the message
string. But what if catgets is used? In that case, a proper index has to be
generated as messages are accessed via them. I guess I'll have to reexamine
the whole gettext stuff to bring me up to date on these matters.
> There is IMO no point in regenerating it every time somebody changes some
> of the source files. Instead, building gcc.pot should be invoked manually,
> by the i18n maintainer, before releasing a catalog to the translators.
Well, you don't exactly directly release it to translators, but as you're a
member of de@li.org (or at least you were the last time I checked :) I think
you know of the issues involved :)
> That would solve this problem, wouldn't it? It would also allow to store
> gcc.pot in the CVS, together with the translations.
Sounds *very* reasonable to me and would indeed eliminate all those
problems.
> Could it be arranged that the relevant dependencies are available only
> under --enable-maintainer-mode?
As Tom allready wrote, that's the thing he did for binutils. And I'll change
gcc to follow that route. Expect a patch sometime next week. Making the core
i18n stuff a maintainer task will eliminate most of the problems. It would
of cause also put the burden of ensuring that POTFILES.in is up-to-date on
said maintainers shoulders, wouldn't it? It wouldn't be much of a problem
though for someone like me who could easily arrange for nightly repo updates
and bootstrapping.
> > That's what I suggested and also posted a patch for.
>
> Hmm. I'd prefer that such patches carry a more prominent subject than
> "GCC 3.0 Release Criteria"... I have extreme difficulties of
> determining whether that patch has been approved or not, or what the
> commentary was.
Point taken. I'll resubmit it under an appropriate subject. I should have
thought of that when posting it in the first place, so thanks for pointing
it out.
> Try to see this from the user's perspective.
Believe me, I am trying to do so, otherwise I wouldn't bother with either
the support or translating gcc.pot into german.
> A number of users would consider it an achievement if gcc would produce
> error messages they could understand even sometimes.
Yes, that would possibly reduce questions like 'what is gcc trying to tell me
here?'. Just on a side note I also envision the comments from those that
don't like it, but you could just tell them to either set LC_MESSAGES=POSIX
or start gcc with 'LC_MESSAGES=POSIX gcc .....'.
> It is quite unlikely that all translation teams finish their translations
> by the time gcc 3.0 is released.
I never assumed that to be case. I'm in this game for to long to assume
anything else ;-)
> So it is very important that this starts very soon, or it won't have
> any effect on the release of gcc 3.
That's why I started pushing the issue in the first place as soon as Mark
came up with the release criteria for 3.0. I would really like to see gcc
3.0 come out with working i18n support. My job with SuSE, part of which is
doing support, has made me change my POV on this issue from 'nice to have'
to 'will satisfy potential customers'. Which is also why I'm volunteering to
become i18n maintainer, BTW :)
Philipp
--
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany
#define NINODE 50 /* number of in core inodes */
#define NPROC 30 /* max number of processes */
-- Version 7 UNIX fuer PDP 11, /usr/include/sys/param.h