Re: New member of the Dutch team

Re: New member of the Dutch team

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

>>>>> "François" == =?ISO-8859-1?Q?Fran=E7ois Pinard?= <ISO-8859-1> writes:

François> By the way, I do not think we have any POT file for
François> `binutils', the `binutils' maintainer should tell me where
François> to find a pretest distribution, from which I could extract
François> the POT file.  Cc:ed.

Hi François.  I've CCd the binutils mailing list.

You can read about binutils, including information on getting
snapshots, here:

http://sourceware.cygnus.com/binutils/

Tom

Re: New member of the Dutch team

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

Tom Tromey <tromey@cygnus.com> écrit:

> You can read about binutils, including information on getting snapshots,
> here: http://sourceware.cygnus.com/binutils/

Just a mere URL of a packaged distribution would do.  FTP or HTTP is fine.
I know that there is a growing trend for avoiding the packaging of pretest
distributions, often in favour of `rsync' or CVS.  The Translation Project
scripts, as well as surely many translators, are still geared towards
traditional methods.  Could this be easily organised?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: New member of the Dutch team

[Ian Lance Taylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

   From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@iro.umontreal.ca>
   Date: 22 Feb 2000 21:51:38 -0500

   Tom Tromey <tromey@cygnus.com> écrit:

   > You can read about binutils, including information on getting snapshots,
   > here: http://sourceware.cygnus.com/binutils/

   Just a mere URL of a packaged distribution would do.  FTP or HTTP is fine.
   I know that there is a growing trend for avoiding the packaging of pretest
   distributions, often in favour of `rsync' or CVS.  The Translation Project
   scripts, as well as surely many translators, are still geared towards
   traditional methods.  Could this be easily organised?

If you look at the cited web page, you will see where to find daily
snapshots of the binutils sources.  These snapshots are close to
packaged distributions--they include all the sources, but not all the
generated files.  You should rebuild the various POT files before
translating them; this can be done automatically by configuring with
--enable-maintainer-mode.

Ian

Re: New member of the Dutch team

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

Ian Lance Taylor <ian@zembu.com> écrit:

> If you look at the cited web page, you will see where to find daily
> snapshots of the binutils sources.  These snapshots are close to
> packaged distributions--they include all the sources, but not all
> the generated files.  You should rebuild the various POT files before
> translating them; this can be done automatically by configuring with
> --enable-maintainer-mode.

It normally works this way.  The maintainer decides when the time comes to
initiate a translation cycle for his package.  This often corresponds to
the production of a pretest release.  At that time, the maintainer sends
the URL of that pretest distribution to me.  I use a script which fetches
the distribution and extract from it the single POT file it contains
-- this has not been a problem so far, as all pretests that we handle
contain exactly one POT file.  That POT file is canonicalised and made
available to the translators, after merged in previous translations if any.
The pretest URL is also publicised to translators.  (At some later time,
the maintainer will be able to trigger the robot into these operations
without going through me -- the main reason it is not possible yet is for
ascertaining the maintainer identity, somewhat).

It is also possible to send the POT file only, outside any distribution.
This is not preferred, as translators often ask for context to resolve
translation ambiguities.  Each POT file has a version identification,
which is usable only once: as two different POT files necessarily have two
different versions.  The version numbers represent the current pretest,
not the incoming official release (this would prevent changing it).
A few schemes for versioning are usable, and new schemes need discussion,
as I would then have to adapt various scripts.

The page http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html
tells about what this message says, more or less.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: New member of the Dutch team

[Ian Lance Taylor]

   From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@iro.umontreal.ca>
   Date: 22 Feb 2000 23:15:33 -0500

   It normally works this way.  The maintainer decides when the time comes to
   initiate a translation cycle for his package.  This often corresponds to
   the production of a pretest release.  At that time, the maintainer sends
   the URL of that pretest distribution to me.  I use a script which fetches
   the distribution and extract from it the single POT file it contains
   -- this has not been a problem so far, as all pretests that we handle
   contain exactly one POT file.  That POT file is canonicalised and made
   available to the translators, after merged in previous translations if any.
   The pretest URL is also publicised to translators.  (At some later time,
   the maintainer will be able to trigger the robot into these operations
   without going through me -- the main reason it is not possible yet is for
   ascertaining the maintainer identity, somewhat).

Well, I have no idea when we will produce a binutils release, so I
have no idea when it would be appropriate to initiate a translation
cycle.  Presumably not now, nor any time soon.  When and if we start a
release cycle, release snapshots will be available from the web page.

For better or worse, a binutils release has six POT files.  After all,
the binutils include both several independent programs and a couple of
libraries.

Ian

Re: New member of the Dutch team

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

Ian Lance Taylor <ian@zembu.com> writes:

> When and if we start a release cycle, release snapshots will be available
> from the web page.

I hope some precise URL could be used and published.  It has to be gettable
with a batch process.  (I would not have the time to do all fetches by hand,
it has to be fairly automated at this end.)

> For better or worse, a binutils release has six POT files.  After all,
> the binutils include both several independent programs and a couple
> of libraries.

I will then have to manage with this situation, when the time comes.
Foresee some time for me to react, when you will be ready.  I hope you use
"reasonable" textual domain names for all your POT files, in the line of
what is being done everywhere else.

Best is still to have a single POT file when possible.  Common LISP is our
biggest so far (if I remember correctly), and `bash' is not the smallest
either, and still, a single POT is sufficient.  Gnome is going to require
many, and when the time of Emacs will come, it will have to be split, too.
I do not remember that `binutils' is especially big, message-wise.

The Translation Project was able to maintain some nomenclature uniformity
until now.  This is possible with the collaboration of all parties involved.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: New member of the Dutch team

[Ian Lance Taylor]

   From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@iro.umontreal.ca>
   Date: 23 Feb 2000 01:30:44 -0500

   Ian Lance Taylor <ian@zembu.com> writes:

   > When and if we start a release cycle, release snapshots will be available
   > from the web page.

   I hope some precise URL could be used and published.  It has to be gettable
   with a batch process.  (I would not have the time to do all fetches by hand,
   it has to be fairly automated at this end.)

There is a precise URL:
    ftp://sourceware.cygnus.com/pub/binutils/snapshots/binutils.tar.bz2
This file is updated daily during the release cycle (and, for that
matter, at other times).

Of course, this is moot as there is no planned binutils release.

   > For better or worse, a binutils release has six POT files.  After all,
   > the binutils include both several independent programs and a couple
   > of libraries.

   I will then have to manage with this situation, when the time comes.
   Foresee some time for me to react, when you will be ready.  I hope you use
   "reasonable" textual domain names for all your POT files, in the line of
   what is being done everywhere else.

   Best is still to have a single POT file when possible.  Common LISP is our
   biggest so far (if I remember correctly), and `bash' is not the smallest
   either, and still, a single POT is sufficient.  Gnome is going to require
   many, and when the time of Emacs will come, it will have to be split, too.
   I do not remember that `binutils' is especially big, message-wise.

   The Translation Project was able to maintain some nomenclature uniformity
   until now.  This is possible with the collaboration of all parties involved.

You really have to talk to Tom Tromey about this, as he set it all up.
I've never really looked into it.  I don't even know what the textual
domain name of a POT file is.

Using several POT files in the binutils has nothing to do with the
size or number of messages.

The binutils include an installed library, libbfd, and installed
programs.  libbfd includes strings, and therefore includes a POT file.
The programs include other strings, and therefore also include POT
files.  Both the binutils and gdb use libbfd, and they are distributed
separately.  I don't see a straightforward way to combine everything
into a single POT file.

Ian

Re: New member of the Dutch team

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

Ian Lance Taylor <ian@zembu.com> writes:

> The binutils include an installed library, libbfd, and installed programs.
> libbfd includes strings, and therefore includes a POT file.  The programs
> include other strings, and therefore also include POT files.  Both the
> binutils and gdb use libbfd, and they are distributed separately.  I don't
> see a straightforward way to combine everything into a single POT file.

A "textual domain" is just a name encompassing a particular POT file and
all national PO files which have been made out of that initial POT file.
The textual domain is used a key to recover the proper PO file at run time.
For example, if the textual domain is `binutils' (that would be proper),
using the default --prefix, the French translations should be held within:

  /usr/local/share/locale/fr/LC_MESSAGES/binutils.mo

So far (Gnome excepted, still in the future), we install one PO file
per language per distribution, that usually means there is one POT file
per distribution, from which PO files are derived.  If for some strange
technical reason a POT file may not be constructed in one shot, we have
combining tools, so this is not really a problem.  Even `xgettext' can
combine POT files, if I remember well.  In my opinion, all programs from
`binutils', as well as any library which is specific to `binutils', could
well share a single textual domain.  This is what we do in other `*utils',
which often have dozens of programs.

However, if `libbfd' is to be part of many distributions, we might have to
seek a compromise between the usual simplicity of a single POT file, and the
fact it would not be reasonable asking translators to re-translate `libbfd'
separately, once per distribution including it.  We do not have a solid,
all-satisfying solution for this problem yet, and since this is going to
happen often, I/we have to think this carefully, so all involved parties
are reasonably satisfied, while avoiding a proliferation of approaches.
Note that diversity is not bad in itself, but it would make the Translation
Project much more difficult to manage, document and use.

Hopefully, since `binutils' is not fully ready for translation yet, this
gives us some time to breath and think.  I will try to work on this in a few
weeks, and then get back to you.  Of course, good ideas are always welcome!

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: New member of the Dutch team

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

François>    I will then have to manage with this situation, when the
François>    time comes.  Foresee some time for me to react, when you
François>    will be ready.  I hope you use "reasonable" textual
François>    domain names for all your POT files, in the line of what
François>    is being done everywhere else.

Ian> You really have to talk to Tom Tromey about this, as he set it all up.

Basically I made each separate "package" its own translation domain.
For instance, BFD uses the "bfd" domain.
"as" and "gasp" are in the "gas" domain.
(The rule is that we use the PACKAGE definition from configure.in as
the domain name.)

Libraries correctly use dgettext to look up messages in their domain.
(See bfd/sysdep.h to see how.)

I still think this is a reasonable approach.  For one thing, it is
easy to understand.  For another, parts of binutils (eg bfd) are
shared with other packages (gdb).

Tom

Re: New member of the Dutch team

[Ken Raeburn]

> Hopefully, since `binutils' is not fully ready for translation yet, this
> gives us some time to breath and think.  I will try to work on this in a few
> weeks, and then get back to you.  Of course, good ideas are always welcome!

You might check with the gdb folks too, if you haven't already.
Looking at their mailing list archives, it looks to me like they may
be gearing up for a major new release (5.0).

Ken

Re: New member of the Dutch team

[Tom Tromey]

>> Hopefully, since `binutils' is not fully ready for translation yet, this
>> gives us some time to breath and think.  I will try to work on this in a few
>> weeks, and then get back to you.  Of course, good ideas are always welcome!

Ken> You might check with the gdb folks too, if you haven't already.
Ken> Looking at their mailing list archives, it looks to me like they may
Ken> be gearing up for a major new release (5.0).

gdb doesn't use gettext.
When I went on my gettextization rampage at Cygnus, I was going to do
gdb, but Stan asked me not to.  At the time he thought HP was going to
do it, but of course they didn't.  Lose, lose.

Tom

Re: New member of the Dutch team

[Ken Raeburn]

> gdb doesn't use gettext.

Oops.

And from some other stuff I dug up in their recent archives, a
proposed release schedule, it'd probably be too late to start on
translations anyways, even if they slipped the schedule a little.
Especially if the supporting code hasn't been written yet....

Re: New member of the Dutch team

[assignments]

I don't see an item for "gettextification" of GNU programs in our
Task List; I just sent a suggestion to RMS to add such an item.

- Brian Y., FSF office staff

Translation Project Support for gdb (Re: New member of the Dutch team)

[Karl Eichwalder]

Ken Raeburn <raeburn@raeburn.org> writes:

> > gdb doesn't use gettext.
> 
> Oops.
> 
> And from some other stuff I dug up in their recent archives, a
> proposed release schedule, it'd probably be too late to start on
> translations anyways, even if they slipped the schedule a little.

Hello you all,

if you'll need help with translation coordination for gdb please drop us
a line (translation@iro.umontreal.ca).  If you wnat me to setup a
textdomain for gdb at http://www.iro.umontreal.ca/contrib/po/HTML/ you
are invited to visit

    http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html

and send all needed info to me.  Hope this helps.

All the best,
Karl

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)