You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <e....@gmx.net> on 2004/05/02 18:18:09 UTC
TRANSLATING: HACKING for translators?
In an effort to organise translation contributions, I wrote the following
document, which I propose to commit as TRANSLATING next to HACKING.
bye,
Erik.
-*- text -*-
If you are contributing code or translations to the Subversion project,
please read this first.
===============================
Guide to translating Subversion
===============================
$LastChangedDate$
* Introduction
* Starting a new translation
* Requirements for po files
* Conventions for the empty string msgid section
* Single versus double quotes
* Translation teams
Introduction
============
Subversion uses gettext for its translation. Gettext uses '.po' files
to store translation information; the existing ones are kept in the
subversion/po directory of the repository.
[Note that the last paragraph deliberately does not say GNU gettext.]
Starting a new translation
==========================
Before starting a new translation please contact the subversion
development mailing list to make sure you are not duplicating efforts.
After that, you should perform the following steps:
Unix
1) check out Subversion (see INSTALL for more information)
2) run ./autogen.sh
3) run ./configure
4) run make locale-gnu-pot
This step is currently only supported for GNU gettext systems
Steps (2) and (3) generate a Makefile; step (4) generates
subversion/po/subversion.pot
Requirements for po files
=========================
Any po file used with Subversion - whether submitted to the project or
used locally - must satisfy two conditions:
1) po files must be UTF-8 encoded
2) the empty string section (msgid "") must not contain a 'charset='
string
These requirements stem from the fact that Subversion uses UTF-8
internally, some implementations translate to the active locale and the
fact that bind_textdomain_codeset() is not portable accross
implementations.
Conventions for the empty string msgid section
==============================================
Some gettext implementations use a section with a msgid "" (empty string)
to keep administrative data. One of the strings suggested is the
'Last-Translator:' field. Because the Subversion project has a policy not
to name names in specific files, but give credit in the repository log
messages, you are requested not to use this field.
Single versus double quotes
===========================
The project has standardised the use of quotes. Some translation teams
have done the same. If there is no translation team for your locale or
they did not standardise quoting, please follow the project guidelines per
HACKING. If they did: follow them :-)
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by Erik Huelsmann <e....@gmx.net>.
> > Isn't it the case that implementations who don't implement
> > bind_textdomain_codeset() doesn't perform any encoding convertion
> > either? If so, I doubt a "charset=UTF-8" would hurt. So I think the
> > requirement 2) should be removed because the enconding specification is
> > surely used by po-editting tools.
>
> If the encoding of the po file (say UTF-8) does not match the active
> locale
> (say iso-8859-1) then at least GNU gettext will translate the UTF-8 from
> the
> po to iso-8859-1 in the presence of a 'charset=' string. When this happens
> the output of *gettext() won't be the required UTF-8...
>
> That's why I don't see any other way than preventing gettext to know what
> to
> translate from. You are ofcourse free to temporarily add them, but they
> can't be in the Subversion repository or the 'compiled' mo...
hmm; also: Brane wants to compile a version of GNU gettext which is compiled
with '#undef HAVE_ICONV'; I don't know if such a compile would export
bind_textdomain_codeset()?
If there were a portable way to tell any gettext not to translate that would
be great; for now this seems to be the way to do it, but if there are
alternatives I'd like to know about them!
bye,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgeb�hr: http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Using bind_textdomain_codeset() after all?
Posted by Branko Čibej <br...@xbc.nu>.
Erik Huelsmann wrote:
>(although this is starting to be a discussion with myself)
>
>There is one more option: Rip out the 'charset=' at build time. Can that be
>done in the Windows build?
>
>
Anything "can be done" in the Windows build if we assume Python is
available. Which we do. :-)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Using bind_textdomain_codeset() after all?
Posted by Erik Huelsmann <e....@gmx.net>.
>
> I forget to add for those falling in the middle that Nicolas argues that
> the
> requirement for the 'charset=' string also stems from po editors depending
> on it to determine which charset to save the file in.
>
> Emacs po mode does seem to do just that...
>
> > > >If the encoding of the po file (say UTF-8) does not match the active
> > > >locale (say iso-8859-1) then at least GNU gettext will translate the
> > > >UTF-8 from the po to iso-8859-1 in the presence of a 'charset='
> string.
> > > >When this happens the output of *gettext() won't be
> > > >the required UTF-8...
> >
> > > >That's why I don't see any other way than preventing gettext to know
> > > >what to translate from. You are ofcourse free to temporarily add
> them,
> > > >but they can't be in the Subversion repository or the 'compiled'
> mo...
> > > >
> > >
> > > I'm saying this:
> > >
> > > Implementations which convert charset and support
> > > bind_textdomain_codeset():
> > > so we call bind_textdomain_codeset() and everything is OK.
> > >
> > > Implementations which do not convert charsets and do not suppoer
> > > bind_textdomain_codeset():
> > > so we make all the .po files UTF-8 encoded.
> > >
> > > Is there an implementation which convert between charsets and do not
> > > support bind_textdomain_codeset()? Only if such an implementation
> exists
> > > it should be required to strip the encoding specification from the .po
> > > files, IMO.
> >
> > I don't know any such system, but only have GNU gettext available and
> know
> > about the existence of the Solaris one. Although I have tried to find
> out
> > I
> > have no idea if this completely describes the problem space. (Usually
> that
> > means it doesn't :-)
(although this is starting to be a discussion with myself)
There is one more option: Rip out the 'charset=' at build time. Can that be
done in the Windows build?
bye,
Erik.
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Using bind_textdomain_codeset() after all?
Posted by Erik Huelsmann <e....@gmx.net>.
I forget to add for those falling in the middle that Nicolas argues that the
requirement for the 'charset=' string also stems from po editors depending
on it to determine which charset to save the file in.
Emacs po mode does seem to do just that...
> > >If the encoding of the po file (say UTF-8) does not match the active
> > >locale (say iso-8859-1) then at least GNU gettext will translate the
> > >UTF-8 from the po to iso-8859-1 in the presence of a 'charset=' string.
> > >When this happens the output of *gettext() won't be
> > >the required UTF-8...
>
> > >That's why I don't see any other way than preventing gettext to know
> > >what to translate from. You are ofcourse free to temporarily add them,
> > >but they can't be in the Subversion repository or the 'compiled' mo...
> > >
> >
> > I'm saying this:
> >
> > Implementations which convert charset and support
> > bind_textdomain_codeset():
> > so we call bind_textdomain_codeset() and everything is OK.
> >
> > Implementations which do not convert charsets and do not suppoer
> > bind_textdomain_codeset():
> > so we make all the .po files UTF-8 encoded.
> >
> > Is there an implementation which convert between charsets and do not
> > support bind_textdomain_codeset()? Only if such an implementation exists
> > it should be required to strip the encoding specification from the .po
> > files, IMO.
>
> I don't know any such system, but only have GNU gettext available and know
> about the existence of the Solaris one. Although I have tried to find out
> I
> have no idea if this completely describes the problem space. (Usually that
> means it doesn't :-)
>
> bye,
>
>
> Erik.
>
> --
> "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
> Jetzt aktivieren unter http://www.gmx.net/info
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgeb�hr: http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Using bind_textdomain_codeset() after all?
Posted by Erik Huelsmann <e....@gmx.net>.
>
> >If the encoding of the po file (say UTF-8) does not match the active
> >locale (say iso-8859-1) then at least GNU gettext will translate the
> >UTF-8 from the po to iso-8859-1 in the presence of a 'charset=' string.
> >When this happens the output of *gettext() won't be
> >the required UTF-8...
> >That's why I don't see any other way than preventing gettext to know
> >what to translate from. You are ofcourse free to temporarily add them,
> >but they can't be in the Subversion repository or the 'compiled' mo...
> >
>
> I'm saying this:
>
> Implementations which convert charset and support
> bind_textdomain_codeset():
> so we call bind_textdomain_codeset() and everything is OK.
>
> Implementations which do not convert charsets and do not suppoer
> bind_textdomain_codeset():
> so we make all the .po files UTF-8 encoded.
>
> Is there an implementation which convert between charsets and do not
> support bind_textdomain_codeset()? Only if such an implementation exists
> it should be required to strip the encoding specification from the .po
> files, IMO.
I don't know any such system, but only have GNU gettext available and know
about the existence of the Solaris one. Although I have tried to find out I
have no idea if this completely describes the problem space. (Usually that
means it doesn't :-)
bye,
Erik.
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>If the encoding of the po file (say UTF-8) does not match the active locale
>(say iso-8859-1) then at least GNU gettext will translate the UTF-8 from the
>po to iso-8859-1 in the presence of a 'charset=' string. When this happens
>the output of *gettext() won't be the required UTF-8...
>
>That's why I don't see any other way than preventing gettext to know what to
>translate from. You are ofcourse free to temporarily add them, but they
>can't be in the Subversion repository or the 'compiled' mo...
>
>
I'm saying this:
Implementations which convert charset and support bind_textdomain_codeset():
so we call bind_textdomain_codeset() and everything is OK.
Implementations which do not convert charsets and do not suppoer
bind_textdomain_codeset():
so we make all the .po files UTF-8 encoded.
Is there an implementation which convert between charsets and do not
support bind_textdomain_codeset()? Only if such an implementation exists
it should be required to strip the encoding specification from the .po
files, IMO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by Erik Huelsmann <e....@gmx.net>.
>
> >Requirements for po files
> >=========================
> >
> >Any po file used with Subversion - whether submitted to the project or
> >used locally - must satisfy two conditions:
> >
> >1) po files must be UTF-8 encoded
> >2) the empty string section (msgid "") must not contain a 'charset='
> > string
> >
> >These requirements stem from the fact that Subversion uses UTF-8
> >internally, some implementations translate to the active locale and the
> >fact that bind_textdomain_codeset() is not portable accross
> >implementations.
> >
>
> Isn't it the case that implementations who don't implement
> bind_textdomain_codeset() doesn't perform any encoding convertion
> either? If so, I doubt a "charset=UTF-8" would hurt. So I think the
> requirement 2) should be removed because the enconding specification is
> surely used by po-editting tools.
If the encoding of the po file (say UTF-8) does not match the active locale
(say iso-8859-1) then at least GNU gettext will translate the UTF-8 from the
po to iso-8859-1 in the presence of a 'charset=' string. When this happens
the output of *gettext() won't be the required UTF-8...
That's why I don't see any other way than preventing gettext to know what to
translate from. You are ofcourse free to temporarily add them, but they
can't be in the Subversion repository or the 'compiled' mo...
bye,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgeb�hr: http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>Requirements for po files
>=========================
>
>Any po file used with Subversion - whether submitted to the project or
>used locally - must satisfy two conditions:
>
>1) po files must be UTF-8 encoded
>2) the empty string section (msgid "") must not contain a 'charset='
> string
>
>These requirements stem from the fact that Subversion uses UTF-8
>internally, some implementations translate to the active locale and the
>fact that bind_textdomain_codeset() is not portable accross
>implementations.
>
>
Isn't it the case that implementations who don't implement
bind_textdomain_codeset() doesn't perform any encoding convertion
either? If so, I doubt a "charset=UTF-8" would hurt. So I think the
requirement 2) should be removed because the enconding specification is
surely used by po-editting tools.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>Also, somewhere in this file or HACKING, I'd like to inform developers of
>the badness of constructing sentences by code, for example the string:
>Error '%s' for '%s'
>where the first part is an action, i.e. "restoring props". We also have
>some cases in the command line client. These might be hard to translate
>into other languages, so it is better to have the complete strings if
>possible. I plan to fix those cases if no one gets to it before me:-), but
>still I think this is good advice for this file.
>
>
Right. Although rather than duplicating these suggestions here, I'd add
a link from HACKING to the relevant parts of the gettext manual, which
contains quite a lot of developer-centric material.
- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by "Peter N. Lundblad" <lu...@softhome.net>.
On Sun, 2 May 2004, Erik Huelsmann wrote:
>
> In an effort to organise translation contributions, I wrote the following
> document, which I propose to commit as TRANSLATING next to HACKING.
>
Good work! An addition for clarity
[...]
> Starting a new translation
> ==========================
>
> Before starting a new translation please contact the subversion
> development mailing list to make sure you are not duplicating efforts.
>
> After that, you should perform the following steps:
>
> Unix
>
> 1) check out Subversion (see INSTALL for more information)
> 2) run ./autogen.sh
> 3) run ./configure
> 4) run make locale-gnu-pot
> This step is currently only supported for GNU gettext systems
5) Copy the generated subversion.pot to a file named LANG.po, where
LANG is the language code of your language.
Also, somewhere in this file or HACKING, I'd like to inform developers of
the badness of constructing sentences by code, for example the string:
Error '%s' for '%s'
where the first part is an action, i.e. "restoring props". We also have
some cases in the command line client. These might be hard to translate
into other languages, so it is better to have the complete strings if
possible. I plan to fix those cases if no one gets to it before me:-), but
still I think this is good advice for this file.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: TRANSLATING: HACKING for translators?
Posted by kf...@collab.net.
"Erik Huelsmann" <e....@gmx.net> writes:
> In an effort to organise translation contributions, I wrote the following
> document, which I propose to commit as TRANSLATING next to HACKING.
I see you're still taking some feedback on the doc, but just wanted to
say +1 on adding this when you're ready (and thanks!).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Erik Huelsmann <e....@gmx.net>.
> > Perhaps put those targets into a separate makefile on subversion/po.
>
> +1
>
> But not having to break the build system in separate pieces would be
> probably better.
It could be an includable part in the main build system, but still be
contained in subversion/po and be a valid Makefile by itself.
I'll see what I can do about it.
Bye,
Erik.
--
+++ Jetzt WLAN-Router f�r alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Pierre THIERRY <pi...@moine-fou.org>.
> Perhaps put those targets into a separate makefile on subversion/po.
+1
But not having to break the build system in separate pieces would be
probably better.
Locally,
Nowhere man
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING:
HACKING for translators?)
Posted by Branko Čibej <br...@xbc.nu>.
Erik Huelsmann wrote:
>>>Presumably because you are a developer (even when you only develop
>>>translations).
>>>
>>>
>>No I'm not. I'm a translator, maybe with little technical knowledge. At
>>least, this kind of user should be able to contribute...
>>
>>
>
>Ok. Point taken. Let me rephrase myself: until your request people following
>trunk for whatever reason were assumed to be knowledgeable of the autoconf
>build support system.
>
>
Funny, I was almost bitten by the same problem today (I'm starting the
Slovenian translation, finally). Turns out that the two make targets
that have to do with translation (locale-gnu-pot and
locale-gnu-po-update) only depend on xgettext and msgmerge. Surely we
could do that without jumping through hoops with configure? Perhaps put
those targets into a separate makefile on subversion/po. There's really
no need for them to depend on the rest of the build system. We can just
assume translators have the gettext tools in the path, and we don't even
have to bother with an objdir != srcdir build.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Pierre THIERRY <pi...@moine-fou.org>.
> To help you with a quick start I could send you the .pot for current
> HEAD off-list.
BTW, I'm a developer, so I finally managed to configure, but the
situation will surely prevent non-tech translators to contribute. And I
could see in other projects, their participation is often needed to have
plenty of localizations.
> Anybody running Subversion has APR, so the only time you won't have
> APR is when you don't run it.
But I had problems with this dependency. I didn't see anywhere what
exactly I had to provide to --with-apr (all docs seem to make the
assumption I had to build it, but in a good distrib, it is packaged, so
I just apt-get installed it).
The only directory of the libapr0 package, in Debian, is /usr/lib, so I
tried it and it failed. It's only because I already used autoconf before
that I thought about giving just /usr. (in fact, it worked before, as I
installed libapr0-dev, which provide apr-config, whose filename was fine
for the --with-apr option, but I wanted to know what directory was to
provide instead)
The fact is that a non-developer translator will not guess that
--with-apr wants what was given in the --with-prefix of the APR
configure. The translator doesn't even know about that prefix stuff...
Easily,
Nowhere man
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Erik Huelsmann <e....@gmx.net>.
> > Presumably because you are a developer (even when you only develop
> > translations).
>
> No I'm not. I'm a translator, maybe with little technical knowledge. At
> least, this kind of user should be able to contribute...
Ok. Point taken. Let me rephrase myself: until your request people following
trunk for whatever reason were assumed to be knowledgeable of the autoconf
build support system.
Surely you should be able to contribute. What you ask is new to Subversion
is all I am saying. Until now we had releases for non-tech users and trunk
for those wanting bleeding edge. To help you with a quick start I could send
you the .pot for current HEAD off-list.
> I don't see the point requesting APR everytime. Isn't it possible that
> autoconf generate only the targets that are possible to build (so when
> APR isn't there?
Anybody running Subversion has APR, so the only time you won't have APR is
when you don't run it. If you don't run it, then you can't follow trunk.
Which you do, since you're translating HEAD (no releases support it yet).
Anyway, if you run configure once, then a file named 'config.nice' is
created. This file contains the command to run configure with whatever
arguments you used last time. Also, there is no need to run configure
everytime you want the .pot; rather, you run configure once and then you run
'svn up' to pull changes from the repository. Only when configure.in or
autogen.sh get changed you need to run the full sequence. (There are one or
two other cases, but this will get you quite far.) What I try to tell you
is that it might seem complex the first time, it might be only that.
I want to help you understand this so you can contribute. I hope I did just
that and not scare you away.
bye,
Erik.
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Pierre THIERRY <pi...@moine-fou.org>.
> Presumably because you are a developer (even when you only develop
> translations).
No I'm not. I'm a translator, maybe with little technical knowledge. At
least, this kind of user should be able to contribute...
I don't see the point requesting APR everytime. Isn't it possible that
autoconf generate only the targets that are possible to build (so when
APR isn't there?
Doubtly,
Nowhere man
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A
Re: Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Erik Huelsmann <e....@gmx.net>.
> > 1) check out Subversion (see INSTALL for more information)
> > 2) run ./autogen.sh
> > 3) run ./configure
> > 4) run make locale-gnu-pot
> > This step is currently only supported for GNU gettext systems
>
> When I saw that the translation status didn't contain fr, I tried to see
> if I would be able to do, or at least start, the translation. So I did a
> checkout, but the ``./configure'' step failed beacuse it didn't find the
> APR library.
>
> Why would I need APR if I just want to get the .pot file, edit it and
> send the patch?
Presumably because you are a developer (even when you only develop
translations). If you are running Subversion you normally already have APR
though. You can point ./configure there with its --with-apr and
--with-apr-util switches.
HTH,
Erik.
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Unneeded APR dependency in ./configure (was Re: TRANSLATING: HACKING for translators?)
Posted by Pierre THIERRY <pi...@moine-fou.org>.
> 1) check out Subversion (see INSTALL for more information)
> 2) run ./autogen.sh
> 3) run ./configure
> 4) run make locale-gnu-pot
> This step is currently only supported for GNU gettext systems
When I saw that the translation status didn't contain fr, I tried to see
if I would be able to do, or at least start, the translation. So I did a
checkout, but the ``./configure'' step failed beacuse it didn't find the
APR library.
Why would I need APR if I just want to get the .pot file, edit it and
send the patch?
Simply,
Nowhere man (aka le Moine Fou)
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A