l10n, i18n

Hi,
	Today I've commited what will be our "base framework" for
	internationalization... Review/comments are welcome.

	Help too :p

	In a first time we probably want to translate only what is visible
	on fproxy; even if we limit us to that, it's still a fair amount of
	work.

	All the framework stands in
	https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/l10n/
	Translations files will be UTF-8 encoded and kept in java
	properties files...

	The first task is to externalize strings... is there a special
	naming convention for keys ? I mean does ClassName.whatever fits
	the purpose or should we look for something a bit more evolved ?

NextGen$

_______________________________________________
Devl mailing list
Devl@...
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: l10n, i18n

Really what is needed here are people fluent in two languages.  The
problem is that this approach imposes aadditional limitations, such as
that they must be familiar with subversion, and not intimidated by
things like java property files.

If you could find a way that non-devs could *easily* contribute
translation files, I suspect this would be a much faster process.

Ian.

On 3/31/07, Florent Daignière (NextGen$)
<nextgens@...> wrote:
> Hi,
>         Today I've commited what will be our "base framework" for
>         internationalization... Review/comments are welcome.
>
>         Help too :p
>
>         In a first time we probably want to translate only what is visible
>         on fproxy; even if we limit us to that, it's still a fair amount of
>         work.
>
>         All the framework stands in
>         https://emu.freenetproject.org/svn/trunk/freenet/src/freenet/l10n/
>         Translations files will be UTF-8 encoded and kept in java
>         properties files...
>
>         The first task is to externalize strings... is there a special
>         naming convention for keys ? I mean does ClassName.whatever fits
>         the purpose or should we look for something a bit more evolved ?

Re: l10n, i18n

* Ian Clarke <ian@...> [2007-03-31 21:02:37]:

> Really what is needed here are people fluent in two languages.  The
> problem is that this approach imposes aadditional limitations, such as
> that they must be familiar with subversion, and not intimidated by
> things like java property files.

Well, we need one way to get the files back ... either using subversion
or mailing lists.

> If you could find a way that non-devs could *easily* contribute
> translation files, I suspect this would be a much faster process.
> 

Ok, understood, I will write a plugin allowing people to edit/export java
property files then :)

NextGen$

_______________________________________________
Devl mailing list
Devl@...
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: l10n, i18n

I can take the spanish stuff. No problem using svn.

On 4/1/07, Florent Daignière (NextGen$) <nextgens <at> freenetproject.org> wrote:
> * Ian Clarke <ian <at> locut.us> [2007-03-31 21:02:37]:
>
> > Really what is needed here are people fluent in two languages.  The
> > problem is that this approach imposes aadditional limitations, such as
> > that they must be familiar with subversion, and not intimidated by
> > things like java property files.
>
> Well, we need one way to get the files back ... either using subversion
> or mailing lists.
>
> > If you could find a way that non-devs could *easily* contribute
> > translation files, I suspect this would be a much faster process.
> >
>
> Ok, understood, I will write a plugin allowing people to edit/export java
> property files then :)
>
> NextGen$
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGD5+MU/Z/dHFfxtcRAtBTAKDRDzQLttO4rRWPooxLk4bbxMlVHwCfbAxJ
> tmmTDvto3W/jG3nO29LsrW4=
> =IFlI
> -----END PGP SIGNATURE-----
>

1026 - Internal error

Internal Error: please report

java.lang.NullPointerException
        at
freenet.store.BerkeleyDBFreenetStore.checkSecondaryDatabaseError(BerkeleyDBFreenetStore.java:1901)
        at
freenet.store.BerkeleyDBFreenetStore.fetch(BerkeleyDBFreenetStore.java:1501)
        at freenet.node.Node.fetch(Node.java:1861)
        at freenet.node.Node.fetch(Node.java:2399)
        at freenet.node.Node.fetchKey(Node.java:2387)
        at
freenet.client.async.ClientRequestScheduler.register(ClientRequestScheduler.java:191)
        at freenet.node.SendableGet.schedule(SendableGet.java:106)
        at freenet.client.async.ClientGetter.start(ClientGetter.java:83)
        at freenet.client.async.ClientGetter.start(ClientGetter.java:60)
        at
freenet.client.HighLevelSimpleClientImpl.fetch(HighLevelSimpleClientImpl.java:128)
        at freenet.clients.http.Toadlet.fetch(Toadlet.java:107)
        at freenet.clients.http.FProxyToadlet.handleGet(FProxyToadlet.java:336)
        at freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:297)
        at
freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:416)
        at java.lang.Thread.run(Thread.java:619)

trying to retrieve ksk@... from the web interface. Frost is also seeing
internal errors with code=17.

Re: 1026 - Internal error

* Jano <alejandro@...> [2007-04-03 10:30:54]:

> Internal Error: please report
> 
> java.lang.NullPointerException
>         at
> freenet.store.BerkeleyDBFreenetStore.checkSecondaryDatabaseError(BerkeleyDBFreenetStore.java:1901)
>         at
> freenet.store.BerkeleyDBFreenetStore.fetch(BerkeleyDBFreenetStore.java:1501)
>         at freenet.node.Node.fetch(Node.java:1861)
>         at freenet.node.Node.fetch(Node.java:2399)
>         at freenet.node.Node.fetchKey(Node.java:2387)
>         at
> freenet.client.async.ClientRequestScheduler.register(ClientRequestScheduler.java:191)
>         at freenet.node.SendableGet.schedule(SendableGet.java:106)
>         at freenet.client.async.ClientGetter.start(ClientGetter.java:83)
>         at freenet.client.async.ClientGetter.start(ClientGetter.java:60)
>         at
> freenet.client.HighLevelSimpleClientImpl.fetch(HighLevelSimpleClientImpl.java:128)
>         at freenet.clients.http.Toadlet.fetch(Toadlet.java:107)
>         at freenet.clients.http.FProxyToadlet.handleGet(FProxyToadlet.java:336)
>         at freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:297)
>         at
> freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:416)
>         at java.lang.Thread.run(Thread.java:619)
> 
> trying to retrieve ksk@... from the web interface. Frost is also seeing
> internal errors with code=17.

Hmm, if you are running the trunk version it means that the JVM/bdb code is

crypto-DSA bugs

Hi,
 working on a class test for DSA.java, as needed for my Google Summer of
Code ranking, I have found two more bugs [another one is already fixed,
after nextgens gave me the repos access] in the current DSA implementation.
It is unlikely that they compare during the normal usage, but since
there are no raised exceptions, I believe they must be fixed.

The first bug is generated by this code [part of DSATest.java, not yet
committed]:

public void testSign_border() {

        BigInteger k = BigInteger.ONE;
        BigInteger q = Global.DSAgroupBigA.getQ().add(BigInteger.ONE);
        BigInteger p = q;
        BigInteger g = p.add(BigInteger.ONE);

        DSAGroup aDSAgroup = new DSAGroup(p,q,g);

        DSAPrivateKey aDSAPrivKey=new DSAPrivateKey(aDSAgroup,randomSource);
        DSAPublicKey aDSAPubKey=new DSAPublicKey(aDSAgroup,aDSAPrivKey);
    DSASignature aSignature=

DSA.sign(aDSAgroup,aDSAPrivKey,k,aDSAPrivKey.getX(),randomSource);

       
assertTrue(DSA.verify(aDSAPubKey,aSignature,aDSAPrivKey.getX(),false));
    }

As there are only few controls over parameters when creating a

Re: 1026 - Internal error

Florent Daignière (NextGen$) wrote:

> * Jano <alejandro@...> [2007-04-03
> 10:30:54]:
> 
>> Internal Error: please report
>> 
>> java.lang.NullPointerException
>>         at
>>
freenet.store.BerkeleyDBFreenetStore.checkSecondaryDatabaseError(BerkeleyDBFreenetStore.java:1901)
>>         at
>> freenet.store.BerkeleyDBFreenetStore.fetch(BerkeleyDBFreenetStore.java:1501)
>>         at freenet.node.Node.fetch(Node.java:1861)
>>         at freenet.node.Node.fetch(Node.java:2399)
>>         at freenet.node.Node.fetchKey(Node.java:2387)
>>         at
>>
freenet.client.async.ClientRequestScheduler.register(ClientRequestScheduler.java:191)
>>         at freenet.node.SendableGet.schedule(SendableGet.java:106)
>>         at freenet.client.async.ClientGetter.start(ClientGetter.java:83)
>>         at freenet.client.async.ClientGetter.start(ClientGetter.java:60)
>>         at
>>
freenet.client.HighLevelSimpleClientImpl.fetch(HighLevelSimpleClientImpl.java:128)
>>         at freenet.clients.http.Toadlet.fetch(Toadlet.java:107)
>>         at
>>         freenet.clients.http.FProxyToadlet.handleGet(FProxyToadlet.java:336)
>>         at
>>        

Re: crypto-DSA bugs

On Tue, Apr 03, 2007 at 09:20:36PM +0200, Sback wrote:
> Hi,
>  working on a class test for DSA.java, as needed for my Google Summer of
> Code ranking, I have found two more bugs [another one is already fixed,
> after nextgens gave me the repos access] in the current DSA implementation.
> It is unlikely that they compare during the normal usage, but since
> there are no raised exceptions, I believe they must be fixed.
> 
> The first bug is generated by this code [part of DSATest.java, not yet
> committed]:
> 
> public void testSign_border() {
>        
>         BigInteger k = BigInteger.ONE;
>         BigInteger q = Global.DSAgroupBigA.getQ().add(BigInteger.ONE);
>         BigInteger p = q;
>         BigInteger g = p.add(BigInteger.ONE);
>        
>         DSAGroup aDSAgroup = new DSAGroup(p,q,g);
>        
>         DSAPrivateKey aDSAPrivKey=new DSAPrivateKey(aDSAgroup,randomSource);
>         DSAPublicKey aDSAPubKey=new DSAPublicKey(aDSAgroup,aDSAPrivKey);
>     DSASignature aSignature=
>                
> DSA.sign(aDSAgroup,aDSAPrivKey,k,aDSAPrivKey.getX(),randomSource);
>        
>        
> assertTrue(DSA.verify(aDSAPubKey,aSignature,aDSAPrivKey.getX(),false));
>     }
> 

FYI: Next Frost release

The next Frost release is the LAST release that accepts messages from
a Frost version
earlier than 20-Jun-2006! Starting with the release after the next one
all Frost messages
must contain a valid unique message id, or the message is revoked by
the receiving Frost.

I don't know if this affects the message code inside freenet, please handle.