> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Could you make a python script that works sort of like what
>> autotools does and could be called by both scons and auto*? We do
>> not want two different code bases for that. And relying on file
>> lists, while a good idea in general, seems fra
Could you make a python script that works sort of like what autotools
does and could be called by both scons and auto*? We do not want two
different code bases for that. And relying on file lists, while a good
idea in general, seems fragile in our case, unless scons and autotools
manage to share t
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> I guess I have to change scons to make autotools happy.
Could you make a python script that works sort of like what autotools
does and could be called by both scons and auto*? We do not want two
different code bases for that. And relying on fi
However, if auto* creates
the po file differently, this will lead to a lot of confusion and
frustration (at least for those with a slow internet connection :-) )
For example, one of the problems is that
autotools:
layouts_l10n.pot: $(top_srcdir)/lib/layouts/*.layout
$(top_srcdir)/lib/layouts/*
Bo Peng schrieb:
The generated po files are different in many places like:
2924c2924
< #: lib/layouts/scrlttr2.layout:207 lib/layouts/amsdefs.inc:186
---
#: lib/layouts/amsdefs.inc:186 lib/layouts/scrlttr2.layout:207
which reflect the order in which inc and layout etc are processed, I
am look
A lot of po file noise was caused by changing the order in which the
messages are extracted from the source files (i.e. the order in which
the source files were processed).
I do hope that this order is the same for the scons and automake build
process. Otherwise, we will see a lot of other giant
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Tue May 1 11:28:19 2007
New Revision: 18145
URL: http://www.lyx.org/trac/changeset/18145
Log:
* po/*.po:
* po/POTFILES.in: another giant po files update;
hopefully, the messages, the source files, and the order, in which
Alfredo Braunstein wrote:
>> Log message:
>> Remove all the cruft needed by the original MVC dialog code.
>
> Hurra!
Indeed. Now I'm off to bed to dream of things other than Graphical
User Interface Independence or Model-View-Controller splits. I feel
fre!!
n 2001.)
$ diffstat dialogs.diff
po/POTFILES.in |5
src/frontends/Dialogs.C| 10
src/frontends/Dialogs.h| 14
src/frontends/controllers/ControlButtons.C | 84 -
src/frontends/controllers/ControlBut
[EMAIL PROTECTED] wrote:
> Removed files:
> lyx-devel/src/frontends/controllers/: ControlButtons.C
> ControlButtons.h
> ControlConnections.C
> ControlConnections.h
> ControlDialog.h
> ControlDialog.tmpl
> ControlDialog_impl.C
> ControlDialog_impl.h GUI.h
> ViewBase.C ViewBase.h
> lyx-devel/src/fro
On Thu, Aug 29, 2002 at 12:21:47PM +0200, Jean-Marc Lasgouttes wrote:
> Does this apply to 1.2.x too?
No, it was a regression
regards
john
--
"Take the ideas you find useful. Try not to get hung up on the labels."
- Jonathan S. Shapiro
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Thu, Aug 29, 2002 at 10:04:23AM +, [EMAIL PROTECTED] wrote:
>> Log message: Fixed the selection problem for insettext/insettabular
>> John reported (as promised ;)
John> thanks
Does this apply to 1.2.x too?
JMarc
On Thu, Aug 29, 2002 at 10:04:23AM +, [EMAIL PROTECTED] wrote:
> Log message:
> Fixed the selection problem for insettext/insettabular John reported
> (as promised ;)
thanks
john
--
"Take the ideas you find useful. Try not to get hung up on the labels."
- Jonathan S. Sh
-n | uniq ) > POTFILES.in-t \
&& echo "src/ext_l10n.h" >> POTFILES.in-t \
&& mv POTFILES.in-t POTFILES.in
[...]
So I generate my own po/POTFILES.in!
Why do we then also have po/POTFILES.in on CVS?
When updating from CVS, I mostly get the message that there are
c
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On Tuesday 20 August 2002 2:14 pm, [EMAIL PROTECTED] wrote:
>> Log message: fix bug 568
Angus> Jean-Marc, this fixes the "senseless" bit but the figure still
Angus> doesn't show up in the Navigate menu. Presumably because that
Ang
On Tuesday 20 August 2002 2:14 pm, [EMAIL PROTECTED] wrote:
> Log message:
> fix bug 568
Jean-Marc, this fixes the "senseless" bit but the figure still doesn't show
up in the Navigate menu. Presumably because that code iterates only over
outermost insets.
Angus
On Thu, 4 Jul 2002, Allan Rae wrote:
[...]
> Again, I see no need for lyx.pot or POTFILES* to be in CVS. Please
> enlighten me if I've missed something.
>
> (Although as I said in my last email srcdir!=builddir is now getting
> to be a problem because the generated form_*.[Ch] files are in
> bui
Allan Rae <[EMAIL PROTECTED]> writes:
| On Wed, 3 Jul 2002, Lars Gullik Bjønnes wrote:
>
>> Allan Rae <[EMAIL PROTECTED]> writes:
>>
>> | They don't need to make a dist. Translaters are usually asked to
>> | download a prelease (ie. a dist) and provide updated translations from
>> | that. So th
On Wed, 3 Jul 2002, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | They don't need to make a dist. Translaters are usually asked to
> | download a prelease (ie. a dist) and provide updated translations from
> | that. So the dist is the only place we need to ensure we h
Allan Rae <[EMAIL PROTECTED]> writes:
| They don't need to make a dist. Translaters are usually asked to
| download a prelease (ie. a dist) and provide updated translations from
| that. So the dist is the only place we need to ensure we have a
| correct copy of POTFILES* and lyx.pot (no need fo
On Wed, 3 Jul 2002, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2 Jul 2002, Lars Gullik Bjønnes wrote:
> >
> >> Allan Rae <[EMAIL PROTECTED]> writes:
[...]
> >> | _Or_ not have it in CVS.
> >>
> >> That is the worst option since we will have a _very_ hard time
Allan Rae <[EMAIL PROTECTED]> writes:
| On Tue, 2 Jul 2002, Lars Gullik Bjønnes wrote:
>
>> Allan Rae <[EMAIL PROTECTED]> writes:
>>
>> | On Sun, 30 Jun 2002, Lars Gullik Bjønnes wrote:
| [...]
>> >> So the solution is either to make all generations of this document to
>> >> use the same sorting
On Tue, 2 Jul 2002, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On Sun, 30 Jun 2002, Lars Gullik Bjønnes wrote:
[...]
> >> So the solution is either to make all generations of this document to
> >> use the same sorting rules, _or_ to not have this file automatically
>
Allan Rae <[EMAIL PROTECTED]> writes:
| On Sun, 30 Jun 2002, Lars Gullik Bjønnes wrote:
>
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Fri, Jun 28, 2002 at 12:49:43AM +0200, Lars Gullik Bjønnes wrote:
>> >> | It changes all the time. Every build it seems to be different. It's
>> >> |
On Sun, 30 Jun 2002, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Fri, Jun 28, 2002 at 12:49:43AM +0200, Lars Gullik Bjønnes wrote:
> >> | It changes all the time. Every build it seems to be different. It's
> >> | pretty useless as a piece of information in a
Andre Poenitz wrote:
> On Mon, Jul 01, 2002 at 12:22:36PM +0200, Jean-Marc Lasgouttes wrote:
>
>>Andre> Then perhaps
>>Andre> tr [A-Z._] [a-zzz] < POTFILES.in | paste - POTFILES.in | sort |
>>Andre> cut -f 2
>>
>>Isn't this completely unportable? What an ugly solution...
>>
>
> What's unportabl
On Mon, Jul 01, 2002 at 12:22:36PM +0200, Jean-Marc Lasgouttes wrote:
> Andre> Then perhaps
> Andre> tr [A-Z._] [a-zzz] < POTFILES.in | paste - POTFILES.in | sort |
> Andre> cut -f 2
>
> Isn't this completely unportable? What an ugly solution...
What's unportable there? I always thought that the
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Mon, Jul 01, 2002 at 11:29:13AM +0200, Lars Gullik Bjønnes
Andre> wrote:
>> Does that handle sorting differences between "a", "." and "_"?
Andre> Hm. No.
>> Also we need the correct filename...
Andre> Then perhaps
Andre> tr
On Mon, Jul 01, 2002 at 11:29:13AM +0200, Lars Gullik Bjønnes wrote:
> Does that handle sorting differences between "a", "." and "_"?
Hm. No.
> Also we need the correct filename...
Then perhaps
tr [A-Z._] [a-zzz] < POTFILES.in | paste - POTFILES.in | sort | cut -f 2
should give a good appro
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jul 01, 2002 at 11:14:36AM +0200, Lars Gullik Bjønnes wrote:
>> we do... and the different sorts, sorts it differently...
>> (that is where we get the problem...)
>
| What about
>
| ... | tr [A-Z] [a-z] | sort
>
| then?
Does that handle sor
On Mon, Jul 01, 2002 at 11:14:36AM +0200, Lars Gullik Bjønnes wrote:
> we do... and the different sorts, sorts it differently...
> (that is where we get the problem...)
What about
... | tr [A-Z] [a-z] | sort
then?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
w
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jul 01, 2002 at 11:01:31AM +0200, Lars Gullik Bjønnes wrote:
>> To me?
>> The manually created one, but that has been shot down a number of
>> times earlier...
>
| Hm... does the order of entries in that file convey any information?
>
| If not,
On Mon, Jul 01, 2002 at 11:01:31AM +0200, Lars Gullik Bjønnes wrote:
> To me?
> The manually created one, but that has been shot down a number of
> times earlier...
Hm... does the order of entries in that file convey any information?
If not, wouldn't it be sufficient just to run 'sort' on POTFIL
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Jun 30, 2002 at 12:26:53PM +0200, Lars Gullik Bjønnes wrote:
>> So the solution is either to make all generations of this document to
>> use the same sorting rules, _or_ to not have this file automatically
>> genereated, but manually edited/crea
On Sun, Jun 30, 2002 at 12:26:53PM +0200, Lars Gullik Bjønnes wrote:
> So the solution is either to make all generations of this document to
> use the same sorting rules, _or_ to not have this file automatically
> genereated, but manually edited/created instead.
So which one is preferable?
Andre
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Jun 28, 2002 at 12:49:43AM +0200, Lars Gullik Bjønnes wrote:
>> | It changes all the time. Every build it seems to be different. It's
>> | pretty useless as a piece of information in a diff.
>>
>> _what_ changes in it?
>
| See attachment.
So
On Friday 28 June 2002 06:50, Andre Poenitz wrote:
> On Fri, Jun 28, 2002 at 12:49:43AM +0200, Lars Gullik Bjønnes wrote:
> > | It changes all the time. Every build it seems to be different. It's
> > | pretty useless as a piece of information in a diff.
> >
> > _what_ changes in it?
>
> See atta
to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.279
diff -u
"Michael A. Koziarski" <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>>Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>>| should this be aded to .cvsignore?
>> | It always shows up in cvs diff, even after a clean
>>| checkout/autogen/configure
>>
>>I guess something in it changed then
Lars Gullik Bjønnes wrote:
>Andre Poenitz <[EMAIL PROTECTED]> writes:
>
>| should this be aded to .cvsignore?
>
>
>| It always shows up in cvs diff, even after a clean
>| checkout/autogen/configure
>
>I guess something in it changed then...
>
>
>
It changes all the time. Every build it seems
Andre Poenitz <[EMAIL PROTECTED]> writes:
| should this be aded to .cvsignore?
>
| It always shows up in cvs diff, even after a clean
| checkout/autogen/configure
I guess something in it changed then...
--
Lgb
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 03-Apr-2002 Lars Gullik Bjønnes wrote:
>
>> other argument... translators cannot pick up an up to date lyx.pot
>> anywhare... except from dists.
>
| You don't answer his real question! Why did you say that his patch has
| consequenses on lyx.pot if i
On Wed, 3 Apr 2002, Lars Gullik Bjønnes wrote:
> | The only good arguement I've heard so far is JMarc's about the
> | rewritten 0.11 probably doing things differently -- hopefully they'll
> | have incorporated something similar into 0.11 so my patch isn't
> | necessary.
>
> other argument... trans
On 03-Apr-2002 Lars Gullik Bjønnes wrote:
> other argument... translators cannot pick up an up to date lyx.pot
> anywhare... except from dists.
You don't answer his real question! Why did you say that his patch has
consequenses on lyx.pot if it doesn't have? Did you see something we don't?
gt; Lars> out of sync with the reality.
>
| What?! What are you on about? Why would lyx.pot be any more out of
| sync with reality than it already is?
>
| In my tree I see:
| [rae@galah ~...LyX/lyx-devel]> ll po/lyx.pot po/POTFILES.in
|8 -rw-r-1 rae rae 6236 Ap
about? Why would lyx.pot be any more out of
sync with reality than it already is?
In my tree I see:
[rae@galah ~...LyX/lyx-devel]> ll po/lyx.pot po/POTFILES.in
8 -rw-r-----1 rae rae 6236 Apr 2 14:31 po/POTFILES.in
168 -rw-r--r--1 rae rae167564 Jul 4 200
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> This simple fix doesn't touch gettext.m4 but works with/around
Allan> it. As such it should be future proof.
Famous last words. In version 0.11 (to which we will soon switch, I
guess), everything is completely rewritten.
JMarc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I completely disagree with this since the lyx.pot will be very
Lars> out of sync with the reality.
Lars> Either we keep it as is, or make the POTFILES.in generation
Lars> manual i.e. we add files to it manually.
Either way, w
Allan Rae <[EMAIL PROTECTED]> writes:
| The attached simple patch re-establishes earlier behaviour where
| it was possible to build lyx without a po/POTFILES.in present.
>
| The trick is to make the newer code in gettext.m4 think that a
| valid po/POTFILES.in exists so it will ge
The attached simple patch re-establishes earlier behaviour where
it was possible to build lyx without a po/POTFILES.in present.
The trick is to make the newer code in gettext.m4 think that a
valid po/POTFILES.in exists so it will generate po/Makefile. Then
remove po/POTFILES.in and when you
ths ago when we last had a big discussion. Something has changed
in the configure script because configure no longer builds po/Makefile
unless po/POTFILES.in already exists. I noticed this when I was
preparing a laptop for use at the linux.conf.au but I haven't gotten
around to investigating f
On Thu, Mar 07, 2002 at 05:45:03PM +, Angus Leeming wrote:
> Do we need this file in cvs? I seem to regenerate it on a regular basis (and
> then have to through it away and cvs update it because the order here is so
> very different from the one you lot create).
go to the archives and sear
Do we need this file in cvs? I seem to regenerate it on a regular basis (and
then have to through it away and cvs update it because the order here is so
very different from the one you lot create).
Angus
Here is the patch to make lyx-1.1.6pre2 compile:
Index: POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.102
diff -u -r1.102 POTFILES.in
--- POTFILES.in 2000/11/21 15:45:42 1.102
54 matches
Mail list logo
