Am 10.05.2016 um 01:50 schrieb Uwe Stöhr:
Am 09.05.2016 um 21:48 schrieb Georg Baum:
Therefore I asked. How do they get the .po files after a string remerge?
I don't know. Maybe from git but I know also that download them via
our TRAC websites. If it is the latter I fear they will get their
Am 09.05.2016 um 21:48 schrieb Georg Baum:
I think it is more important to please the translators.
Therefore I asked. How do they get the .po files after a string remerge?
I don't know. Maybe from git but I know also that download them via our
TRAC websites. If it is the latter I fear they
Am 09.05.2016 um 01:34 schrieb Uwe Stöhr:
Am 08.05.2016 um 22:36 schrieb Georg Baum:
3) A translator sends a .po file with unix line ends
4) A translator sends a .po file with windows line ends
The question is how can I check this?
You don't need to check that, but if you want, open the fi
Am Montag, 9. Mai 2016 um 01:34:52, schrieb Uwe Stöhr
> Am 08.05.2016 um 22:36 schrieb Georg Baum:
>
> > 3) A translator sends a .po file with unix line ends
> > 4) A translator sends a .po file with windows line ends
>
> The question is how can I check this?
>
> > For cases 1) and 3) a commit
Am 08.05.2016 um 22:36 schrieb Georg Baum:
3) A translator sends a .po file with unix line ends
4) A translator sends a .po file with windows line ends
The question is how can I check this?
For cases 1) and 3) a commit is OK, for cases 2) and 4) a commit would
produce a huge pseudo diff.
W
Kornel Benko wrote:
>
> I was not accusing anyone.
No problem. I interpreted the exclamation mark like it was not clear why the
commit wnet to master.
Georg
Am Sonntag, 24. April 2016 um 16:12:52, schrieb Georg Baum
> Kornel Benko wrote:
>
> > No, I compared with the file in repository.
> > Why do we have POTFILES.in in repo?
>
> It should not be there, and I can't see it in the repo.
Somehow I created this file with automake.
I did not see anythi
On Sun, Apr 24, 2016 at 11:07:59AM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
>
> > On Thu, Apr 21, 2016 at 10:20:53PM +0200, Georg Baum wrote:
> >
> >> Unless somebody has an idea how to quickly work around the line ending
> >> bug my guess would be that the best option would be that Uwe
On Sun, Apr 24, 2016 at 04:12:52PM +0200, Georg Baum wrote:
> > Thanks, that explains it. I was misled by your last commit to (master!)
> > fr.gmo.
>
> Scott said in this thread that he was fine with whatever I decide for 2.2.0.
+1
Scott
signature.asc
Description: PGP signature
Kornel Benko wrote:
> No, I compared with the file in repository.
> Why do we have POTFILES.in in repo?
It should not be there, and I can't see it in the repo.
> Thanks, that explains it. I was misled by your last commit to (master!)
> fr.gmo.
Scott said in this thread that he was fine with wha
Am Sonntag, 24. April 2016 um 14:47:42, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Am Sonntag, 24. April 2016 um 11:20:16, schrieb Georg Baum
> >
> >> Kornel Benko wrote:
> >>
> >> > Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko
> >> >> Hm, there are more differences. In cma
Kornel Benko wrote:
> Am Sonntag, 24. April 2016 um 11:20:16, schrieb Georg Baum
>
>> Kornel Benko wrote:
>>
>> > Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko
>> >> Hm, there are more differences. In cmake we add also header files to
>> >> the list. But I wonder, why unix command
Am Sonntag, 24. April 2016 um 10:56:54, schrieb Jean-Pierre Chrétien
> Le 24/04/2016 10:37, Jean-Pierre Chrétien a écrit :
>
> >> I think you already committed, if I understood correctly. If you did
> >> not, please go ahead and commit. At worst case we will just revert.
> >
> > I checked on tra
Am Sonntag, 24. April 2016 um 11:20:16, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko
> >> Hm, there are more differences. In cmake we add also header files to the
> >> list. But I wonder, why unix command 'sort' is not working the sa
Kornel Benko wrote:
> Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko
>> Hm, there are more differences. In cmake we add also header files to the
>> list. But I wonder, why unix command 'sort' is not working the same as
>> cmake internal sort.
>
> OK, setting env LC_ALL=C, sort behav
Scott Kostyshak wrote:
> On Thu, Apr 21, 2016 at 10:20:53PM +0200, Georg Baum wrote:
>
>> Unless somebody has an idea how to quickly work around the line ending
>> bug my guess would be that the best option would be that Uwe does the
>> remerge, then sends the resulting files to me, I remove the
Le 24/04/2016 10:37, Jean-Pierre Chrétien a écrit :
I think you already committed, if I understood correctly. If you did
not, please go ahead and commit. At worst case we will just revert.
I checked on trac, all is fine, thanks.
In fact, messages ordering is different, but I guess that it i
Le 24/04/2016 03:25, Scott Kostyshak a écrit :
On Fri, Apr 22, 2016 at 11:43:41AM +0100, Jean-Pierre Chrétien wrote:
Le 22/04/2016 06:14, Georg Baum a écrit :
We really need to stop using two build systems. For now, I would suggest
that a remerge of all languages is done using cmake ASAP.
I
On Thu, Apr 21, 2016 at 10:20:53PM +0200, Georg Baum wrote:
> Unless somebody has an idea how to quickly work around the line ending bug
> my guess would be that the best option would be that Uwe does the remerge,
> then sends the resulting files to me, I remove the stray \r and submit.
Whateve
On Fri, Apr 22, 2016 at 11:43:41AM +0100, Jean-Pierre Chrétien wrote:
> Le 22/04/2016 06:14, Georg Baum a écrit :
>
> >
> > We really need to stop using two build systems. For now, I would suggest
> > that a remerge of all languages is done using cmake ASAP.
> >
> If this does not take place ver
Am Samstag, 23. April 2016 um 14:11:15, schrieb Jean-Pierre Chrétien
> Le 23/04/2016 11:18, Kornel Benko a écrit :
>
> >
> > OK, it is searching for QT. Can you post the command you use for automake?
> > I can try to find the appropriate cmake parameters.
>
> I ran automake (without arguments)
Le 23/04/2016 11:18, Kornel Benko a écrit :
OK, it is searching for QT. Can you post the command you use for automake?
I can try to find the appropriate cmake parameters.
I ran automake (without arguments) in the source tree without success.
Should I give a location for QT libraries?
I do not
Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko
> Am Samstag, 23. April 2016 um 11:42:25, schrieb Kornel Benko
> > Am Samstag, 23. April 2016 um 11:13:46, schrieb Georg Baum
> >
> > > Jean-Marc Lasgouttes wrote:
> > >
> > > > Le 22/04/2016 07:14, Georg Baum a écrit :
> > > >> Afte
Am Samstag, 23. April 2016 um 12:10:25, schrieb Jean-Pierre Chrétien
> > Do you need a recipe?
>
> I've got one already, that I used successfully to try to run the autotests:
>
> http://article.gmane.org/gmane.editors.lyx.devel/160816
>
> However, I try it on my master clone, I get this
>
>
Le 23/04/2016 09:12, Kornel Benko a écrit :
Am Freitag, 22. April 2016 um 22:39:31, schrieb Jean-Pierre Chrétien
Le 22/04/2016 15:20, Kornel Benko a écrit :
Am Freitag, 22. April 2016 um 11:43:41, schrieb Jean-Pierre Chrétien
Le 22/04/2016 06:14, Georg Baum a écrit :
We really need to s
Am Samstag, 23. April 2016 um 11:42:25, schrieb Kornel Benko
> Am Samstag, 23. April 2016 um 11:13:46, schrieb Georg Baum
>
> > Jean-Marc Lasgouttes wrote:
> >
> > > Le 22/04/2016 07:14, Georg Baum a écrit :
> > >> After the remerge with cmake, I get
> > >> this in the diff of de.po (the last r
Am Samstag, 23. April 2016 um 11:13:46, schrieb Georg Baum
> Jean-Marc Lasgouttes wrote:
>
> > Le 22/04/2016 07:14, Georg Baum a écrit :
> >> After the remerge with cmake, I get
> >> this in the diff of de.po (the last remerge of it was on windows):
> >>
> >> -#: src/frontends/qt4/ui/BibitemUi.u
Jean-Marc Lasgouttes wrote:
> Le 22/04/2016 07:14, Georg Baum a écrit :
>> After the remerge with cmake, I get
>> this in the diff of de.po (the last remerge of it was on windows):
>>
>> -#: src/frontends/qt4/ui/BibitemUi.ui:54
>> src/frontends/qt4/ui/RefUi.ui:190 +#:
>> src/frontends/qt4/ui/Bibit
Am Freitag, 22. April 2016 um 22:39:31, schrieb Jean-Pierre Chrétien
> Le 22/04/2016 15:20, Kornel Benko a écrit :
> > Am Freitag, 22. April 2016 um 11:43:41, schrieb Jean-Pierre Chrétien
> >
> >> Le 22/04/2016 06:14, Georg Baum a écrit :
> >>
> >>>
> >>> We really need to stop using two build
Le 22/04/2016 15:20, Kornel Benko a écrit :
Am Freitag, 22. April 2016 um 11:43:41, schrieb Jean-Pierre Chrétien
Le 22/04/2016 06:14, Georg Baum a écrit :
We really need to stop using two build systems. For now, I would suggest
that a remerge of all languages is done using cmake ASAP.
If
Le 22/04/2016 07:14, Georg Baum a écrit :
After the remerge with cmake, I get
this in the diff of de.po (the last remerge of it was on windows):
-#: src/frontends/qt4/ui/BibitemUi.ui:54 src/frontends/qt4/ui/RefUi.ui:190
+#: src/frontends/qt4/ui/BibitemUi.ui:54 src/frontends/qt4/ui/LabelUi.ui:36
Am Freitag, 22. April 2016 um 11:43:41, schrieb Jean-Pierre Chrétien
> Le 22/04/2016 06:14, Georg Baum a écrit :
>
> >
> > We really need to stop using two build systems. For now, I would suggest
> > that a remerge of all languages is done using cmake ASAP.
> >
> If this does not take place very
Le 22/04/2016 06:14, Georg Baum a écrit :
We really need to stop using two build systems. For now, I would suggest
that a remerge of all languages is done using cmake ASAP.
If this does not take place very soon, may I edit the French po file I built
locally and push it? I won't be able to sub
Kornel Benko wrote:
> Am Donnerstag, 21. April 2016 um 22:20:53, schrieb Georg Baum
>
>> This is unfortunately difficult:
>>
>> - If Uwe does a remerge we will get the broken line endings again.
>> - If Jean-Pierre or I do a remerge we will get an exploded diff (32 MiB
>> for all languages) beca
Am Donnerstag, 21. April 2016 um 22:20:53, schrieb Georg Baum
> Scott Kostyshak wrote:
>
> > On Thu, Apr 21, 2016 at 08:13:18AM +0100, Jean-Pierre Chrétien wrote:
> >> Le 20/04/2016 18:19, Scott Kostyshak a écrit :
> >> > On Wed, Apr 20, 2016 at 02:19:50PM +0100, Jean-Pierre Chrétien wrote:
> >>
Scott Kostyshak wrote:
> On Thu, Apr 21, 2016 at 08:13:18AM +0100, Jean-Pierre Chrétien wrote:
>> Le 20/04/2016 18:19, Scott Kostyshak a écrit :
>> > On Wed, Apr 20, 2016 at 02:19:50PM +0100, Jean-Pierre Chrétien wrote:
>>
>> > > There has been a remerge since my last update, without new
>> > > t
On Thu, Apr 21, 2016 at 08:13:18AM +0100, Jean-Pierre Chrétien wrote:
> Le 20/04/2016 18:19, Scott Kostyshak a écrit :
> > On Wed, Apr 20, 2016 at 02:19:50PM +0100, Jean-Pierre Chrétien wrote:
>
> > > There has been a remerge since my last update, without new translations
> > > needed, so the answ
Le 20/04/2016 18:19, Scott Kostyshak a écrit :
On Wed, Apr 20, 2016 at 02:19:50PM +0100, Jean-Pierre Chrétien wrote:
There has been a remerge since my last update, without new translations
needed, so the answer seems to be no.
Just to be sure...
It could be the layout commits, for which I d
On Wed, Apr 20, 2016 at 02:19:50PM +0100, Jean-Pierre Chrétien wrote:
> Hello,
>
> I'm not sure to have correctly understood the threads
> about the release of 2.2.0.
> Will a string translation round be necessary before the release ?
> As far as fr.po is concerned, I have :
>
> "POT-Creation-Dat
Kornel Benko wrote:
> Am Donnerstag, 7. April 2016 um 17:02:42, schrieb Richard Heck
>
>>
>> Maybe a simple solution would be to add something into CMakeLists.txt
>> that would strip all the "\r" before sending the files through gettext.
>
> Maybe, see my other mail. But I prefer the solution w
Richard Heck wrote:
> On 04/09/2016 11:36 AM, Uwe Stöhr wrote:
>> Am 07.04.2016 um 23:37 schrieb Richard Heck:
>>
>>> Then maybe the solution is to disable the writing of native line
>>> endings. Apparently, we can do this by opening the output files in
>>> binary mode. The attached patch does thi
Richard Heck wrote:
> No, it's bad. I'm faikrly sure there should be almost no difference
> between the files if it is working correctly. Something has happend
> involving this sort of thing:
>
> -#: src/frontends/qt4/ui/WrapUi.ui:173 src/frontends/qt4/GuiParagraph.cpp:163
> +#: src/frontends/qt4/
On 04/09/2016 11:36 AM, Uwe Stöhr wrote:
> Am 07.04.2016 um 23:37 schrieb Richard Heck:
>
>> Then maybe the solution is to disable the writing of native line
>> endings. Apparently, we can do this by opening the output files in
>> binary mode. The attached patch does this. Can someone test?
>
> Thi
Richard Heck wrote:
> The attached patch does this. Can someone test?
More precisely, Uwe could you remerge strings using this patch on clean master
and give us single sample .po file so we can check it is identical when we
remerge it on linux machines?
Pavel
On 04/07/2016 05:21 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> I think the problem may not be that gettext works differently but,
>> perhaps, that it works the same. I am guessing that what happens is this.
>> First, lyx_pot.py writes the po files with native line endings.
> Yep, that might e
Richard Heck wrote:
> I think the problem may not be that gettext works differently but,
> perhaps, that it works the same. I am guessing that what happens is
> this. First, lyx_pot.py writes the po files with native line endings.
Yep, that might explain the original problem, why line wrapping is
Am Donnerstag, 7. April 2016 um 17:02:42, schrieb Richard Heck
> On 04/07/2016 04:26 PM, Pavel Sanda wrote:
> > Richard Heck wrote:
> >> Using autotools, this is done via the msguniq program. I cannot tell how
> >> it is done with cmake, but I suspect that this is where the error
> >> occurs, and
Am Donnerstag, 7. April 2016 um 13:26:05, schrieb Pavel Sanda
> Richard Heck wrote:
> > Using autotools, this is done via the msguniq program. I cannot tell how
> > it is done with cmake,
It is the same with cmake.
po/lyx_pot.py -> *_l10n.pot
po/cat.py: *_l10n.pot -> lyx.cat_tmp.pot
po/dos2un
On 04/07/2016 04:26 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> Using autotools, this is done via the msguniq program. I cannot tell how
>> it is done with cmake, but I suspect that this is where the error
>> occurs, and that this is why you get "\r" in the middle of some lines,
>> namely, we g
Richard Heck wrote:
> Using autotools, this is done via the msguniq program. I cannot tell how
> it is done with cmake, but I suspect that this is where the error
> occurs, and that this is why you get "\r" in the middle of some lines,
> namely, we get:
Then we are back at the old problem we were
On 04/07/2016 03:13 PM, Pavel Sanda wrote:
> Georg Baum wrote:
>> Pavel Sanda wrote:
>>> Georg Baum wrote:
python script we should forbid .po file remerging on windows IMHO.
>>> Except it is Uwe who took the burden to be recipient of po updates sent to
>>> po-upda...@lyx.org and care for them
Georg Baum wrote:
> Pavel Sanda wrote:
> > Georg Baum wrote:
> >> python script we should forbid .po file remerging on windows IMHO.
> >
> > Except it is Uwe who took the burden to be recipient of po updates sent
> > to po-upda...@lyx.org and care for them in the long term fashion...
> > Pavel
>
Am Mittwoch, 6. April 2016 um 23:58:20, schrieb Uwe Stöhr
> Am 05.04.2016 um 10:16 schrieb Kornel Benko:
>
> > Recently someone probably merged the po files on a windows system.
>
> Yes, this was me.
> as described in our file README.localization I did:
>
> "
> - on Windows: either build the up
Am 05.04.2016 um 10:16 schrieb Kornel Benko:
Recently someone probably merged the po files on a windows system.
Yes, this was me.
as described in our file README.localization I did:
"
- on Windows: either build the update-po target in MSVC
or run the command: msbuild po\update-p
Pavel Sanda wrote:
> Georg Baum wrote:
>> python script we should forbid .po file remerging on windows IMHO.
>
> Except it is Uwe who took the burden to be recipient of po updates sent
> to po-upda...@lyx.org and care for them in the long term fashion...
> Pavel
Yes, fixing the python script wou
Georg Baum wrote:
> python script we should forbid .po file remerging on windows IMHO.
Except it is Uwe who took the burden to be recipient of po updates sent
to po-upda...@lyx.org and care for them in the long term fashion...
Pavel
On Tue, Apr 05, 2016 at 09:08:35PM +0200, Georg Baum wrote:
> Kornel Benko wrote:
>
> > Nice article. So for us it would suffice to create '.gitattributes' file
> > with the content: *.po text
>
> I fixed the .po files with some sed magic now (like I did already in
> november).
Thanks for doing
Kornel Benko wrote:
> Nice article. So for us it would suffice to create '.gitattributes' file
> with the content: *.po text
Almost. The last time I investigated this I was about to add the attached
one, but it is not enough. Not only the line ends of the files are broken,
but they do contain a
Am Dienstag, 5. April 2016 um 10:27:55, schrieb Richard Heck
> On 04/05/2016 06:17 AM, Kornel Benko wrote:
> > Am Dienstag, 5. April 2016 um 11:45:50, schrieb Jean-Marc Lasgouttes
> >
> >> Le 05/04/2016 11:10, Kornel Benko a écrit :
> You mean by using a .gitattributes file?
> >>> Yes, but
On 04/05/2016 06:17 AM, Kornel Benko wrote:
> Am Dienstag, 5. April 2016 um 11:45:50, schrieb Jean-Marc Lasgouttes
>
>> Le 05/04/2016 11:10, Kornel Benko a écrit :
You mean by using a .gitattributes file?
>>> Yes, but maybe there are better possibilities.
>>> I checked that we do not have lo
Am Dienstag, 5. April 2016 um 11:45:50, schrieb Jean-Marc Lasgouttes
> Le 05/04/2016 11:10, Kornel Benko a écrit :
> >> You mean by using a .gitattributes file?
> >
> > Yes, but maybe there are better possibilities.
> > I checked that we do not have local attributes file yet, still the .cpp
> >
Le 05/04/2016 11:10, Kornel Benko a écrit :
You mean by using a .gitattributes file?
Yes, but maybe there are better possibilities.
I checked that we do not have local attributes file yet, still the .cpp sources
are handled correctly.
From what I understand, it would be nice to have a gitat
Am Dienstag, 5. April 2016 um 10:28:29, schrieb Jean-Marc Lasgouttes
> Le 05/04/2016 10:16, Kornel Benko a écrit :
> > Recently someone probably merged the po files on a windows system.
> > Now the files have a mix of and terminated lines.
> >
> > Could we declare *.po as text files (like *.cp
Le 05/04/2016 10:16, Kornel Benko a écrit :
Recently someone probably merged the po files on a windows system.
Now the files have a mix of and terminated lines.
Could we declare *.po as text files (like *.cpp or *.h)?
You mean by using a .gitattributes file?
JMarc
Jürgen Spitzmüller wrote:
> > Jürgen, there is someting, I don't understand.
> > After todays update there are 1400 messages lost in all po-files. Seems
> > not intended doesn't it?
>
> certainly not. Seems something is messed up here on my side. I'll have a
> look.
>
> I retract the 1.6.7 releas
Kornel Benko wrote:
> Jürgen, there is someting, I don't understand.
> After todays update there are 1400 messages lost in all po-files. Seems not
> intended doesn't it?
certainly not. Seems something is messed up here on my side. I'll have a look.
I retract the 1.6.7 release for the time being.
I would like to commit. We are using perl in cmake at other places too, so the
step to python should be made later anyway. What do you think?
The attached, I think, is a python version. Neither it nor the perl
version gives any output for me, though, so I'm not sure it's correct.
rh
#! /
I would like to commit. We are using perl in cmake at other places too, so the
step to python should be made later anyway. What do you think?
The attached, I think, is a python version. Neither it nor the perl
version gives any output for me, though, so I'm not sure it's correct.
rh
#!
Am Freitag 09 Juli 2010 schrieb Pavel Sanda:
> Kornel Benko wrote:
> > > i'm not against some script for the sake of cmake, but must be pythonic
> > > one
> > >
> > > pavel
> >
> > I knew. But my python skills are bad.
> > Nonetheless, it's ready and fast with perl now.
> >
> > This is the p
Kornel Benko wrote:
> > i'm not against some script for the sake of cmake, but must be pythonic
> > one
> >
> > pavel
>
> I knew. But my python skills are bad.
> Nonetheless, it's ready and fast with perl now.
>
> This is the perl script, maybe someone can write it in python?
if we provide
Am Donnerstag 08 Juli 2010 schrieb Pavel Sanda:
> Kornel Benko wrote:
> > Am Donnerstag 08 Juli 2010 schrieb Kornel Benko:
> > > > but thats already done in "Rules-lyx", no?
> > > > pavel
> > >
> > > Already found that. Coding now.
> > >
> > > Kornel
> >
> > Grrrm ... working, but sooo s
Kornel Benko wrote:
> Am Donnerstag 08 Juli 2010 schrieb Kornel Benko:
> > > but thats already done in "Rules-lyx", no?
> > > pavel
> >
> > Already found that. Coding now.
> > Kornel
>
> Grrrm ... working, but sooo slow.
>
> In cshell it is soo easy
> grep -l '_(\".*\")' file1, fi
Am Donnerstag 08 Juli 2010 schrieb Kornel Benko:
> > but thats already done in "Rules-lyx", no?
> > pavel
>
> Already found that. Coding now.
> Kornel
Grrrm ... working, but sooo slow.
In cshell it is soo easy
grep -l '_(\".*\")' file1, file2, ...
but in cmake one has to read th
Am Donnerstag 08 Juli 2010 schrieb Pavel Sanda:
> Kornel Benko wrote:
> > What we could do, is to define exact algorithm how to generate this
> > file, specifying maybe regular expressions to select filenames from
> > specific directories.
>
> but thats already done in "Rules-lyx", no?
> pavel
A
Kornel Benko wrote:
> What we could do, is to define exact algorithm how to generate this file,
> specifying maybe
> regular expressions to select filenames from specific directories.
but thats already done in "Rules-lyx", no?
pavel
Am Freitag 05 Februar 2010 schrieb Jürgen Spitzmüller:
> Kornel Benko wrote:
> > Changing de-alt into de_alt makes it work though.
>
> But is wrong. "de-alt" is intentional.
>
> Jürgen
>
Sorry ...
Kornel
signature.asc
Description: This is a digitally signed message part.
Kornel Benko wrote:
> Changing de-alt into de_alt makes it work though.
But is wrong. "de-alt" is intentional.
Jürgen
Am Donnerstag 04 Februar 2010 schrieb Vincent van Ravesteijn:
> Kornel Benko schreef:
> > Hi,
> > this string is (in branch and trunk) used ( in Preferences->Language
> > Settings->Language->User interface language: ), but is not part of
> > po-files, thus will not be translated in the GUI.
> >
> >
Kornel Benko schreef:
Hi,
this string is (in branch and trunk) used ( in Preferences->Language
Settings->Language->User interface language: ),
but is not part of po-files, thus will not be translated in the GUI.
Kornel
Then you have to do a remerge.
Vincent
> "Adrien" == Adrien Rebollo <[EMAIL PROTECTED]> writes:
Adrien> This script is diabolic... more than 60 warnings. I fixed
Adrien> about half of them, and here is the patch. I will check the
Adrien> shortcuts later.
Thanks. It is in now.
JMarc
Le lun 10/03/2003 à 14:19, Jean-Marc Lasgouttes a écrit :
> > "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
>
> Michael> Hello, I have written a tiny Perl script (pochecks.pl) that
> Michael> checks the consistency of a given po file:
> [...]
>
> Nicely done. I tried it on fr.po an
On Monday 10 March 2003 14:16, [EMAIL PROTECTED] wrote:
>
> I told you that the script produces false positives... However,
> Claus, Alfredo, and Jean-Marc already found a few real mistakes in
> their po files.
You can add me to such set. ;-)
> Michael
--
José Abílio
Lars Gullik Bjønnes <[EMAIL PROTECTED]> schrieb am 10.03.2003, 15:06:53:
> What is a redundant shortcut?
A shortcut that is introduced in the translated message but does not
occur in the orignal (English) message. I apologize if the word
"redundant" is inappropriate in this context.
> Note that
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Also here | Missing or redundant QT shortcut: | QT should be Qt,
Lars> since this is after all a script for the pedantics | among us.
Lars> What is a redundant shortcut?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Also here
| Missing or redundant QT shortcut:
| QT should be Qt, since this is after all a script for the pedantics
| among us.
What is a redundant shortcut?
Note that missing shortcut is perfectly sane...
--
Lgb
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hello, I have written a tiny Perl script (pochecks.pl) that
Michael> checks the consistency of a given po file:
[...]
Nicely done. I tried it on fr.po and indeed it uncovers a few things.
What would be nice (but probably di
Michael Schmitt wrote:
> Although the script produces a few false positive (11 for de.po), I
> think that other translators will also benefit from it. Therefore, it
Good idea, I'll try it on es.po.
Thanks,
Alfredo
87 matches
Mail list logo
