You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Felix Knecht <fe...@otego.com> on 2010/01/22 20:57:34 UTC
[ApacheDS] I18n
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ufff there's a LOT more than I thought, Exception all over the place.
Anyway ...
If nobody raises important objections the way I implemented, I'll carry
on with i18n-tifying the apacheds module. There may be various equal entries
in the errors.properties file for translation, but it's not amusing to
grep each time I find a new Exception text all existing entries for
existance. I'll do in in the end. This will produce gaps in error
numbering, but also leave space for more ;)
Regards
Felix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktaAy4ACgkQ2lZVCB08qHEJmwCgrZ710AG5zeMoX9Cx0bjxywek
FOsAn2z0WJIN0DWrLkf8wdjiYs9s7AVM
=tTZR
-----END PGP SIGNATURE-----
Re: [ApacheDS] I18n
Posted by Felix Knecht <fe...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> "mvn clean install" is passing well
>> "mvn clean install -Dintegration":
>> - JDK1.6 is hanging in StockServerISuite test case
>> - JDK1.5 fails with error [2]
>>
> Will check that...
Thanks. I don't know if there are any error messages used in
assertEquals in test cases. They will fail now because of the added
ERR_xxx as message prefix.
>> For translation of non error message we have 2 possibilites (because no
>> error code is needed):
>> a) Use the same method as for the error codes and have a MSG_xxx key for
>> each message
>> b) Use inline messages (see also [1])). Doing so the inline messages are
>> used as keys if existing in the i18n-properties file. As translators
>> need to know which inlines can be used as keys the need to be put into
>> the default properties file (but commented) for having a list of
>> available keys
>>
>
> I would say #1.
2 responses, 2 different opinions. Maybe we get a third one or the PMC
chair makes a decision?
> Just a side question : can't we define a range par project? For
> instance, apacheds-core would use errors between 1000 and 1999,
> shared-ldap use from 12000 to 12999, etc ? Just in order to be able to
> add errors which describes the project they have been generated in, and
> gives us a clue about what's going on ? Just wondering ...
Yes, we can! This is a jira entry worth for the refactoring IMO.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktdyckACgkQ2lZVCB08qHHYQACghgoHKAMnOcXV1GR6XzT/Wmr2
xooAoJWbWwVaH7BGzmPq3VhBOL1LeQuZ
=f/J/
-----END PGP SIGNATURE-----
Re: [ApacheDS] I18n
Posted by Emmanuel Lecharny <el...@gmail.com>.
Felix Knecht a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Finally I did it. Most of the error messages are now ready for i18n (and
> translations). I hope that all messages have been replaced correctly and
> that still the same error message is shown in case, but I don't know how
> I could test this.
> Duplicates have been replaced and commented where available. I leave the
> commented duplicates in the code and properties-file. This way obvious,
> which ERR_xxx can be used when adding new error messages.
>
> "mvn clean install" is passing well
> "mvn clean install -Dintegration":
> - JDK1.6 is hanging in StockServerISuite test case
> - JDK1.5 fails with error [2]
>
Will check that...
> For translation of non error message we have 2 possibilites (because no
> error code is needed):
> a) Use the same method as for the error codes and have a MSG_xxx key for
> each message
> b) Use inline messages (see also [1])). Doing so the inline messages are
> used as keys if existing in the i18n-properties file. As translators
> need to know which inlines can be used as keys the need to be put into
> the default properties file (but commented) for having a list of
> available keys
>
I would say #1.
Otherwise, congrats for the great work ! Now, up to the translations ;)
Just a side question : can't we define a range par project? For
instance, apacheds-core would use errors between 1000 and 1999,
shared-ldap use from 12000 to 12999, etc ? Just in order to be able to
add errors which describes the project they have been generated in, and
gives us a clue about what's going on ? Just wondering ...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: [ApacheDS] I18n
Posted by Felix Knecht <fe...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> Using FQCN as prefix will make it impossible to avoid duplicated
>> translations.
>
> You mean, when the exact same message is used by two separate classes?
Exactly
> If yes, in that case, you're right, a global key without any prefix would be more appropriate.
>
>
> One more question about possibility "a": Does this possibility mean that for each message a "public static String" would be created for the key in a class or interface, as well as the same key (with the translated value) in the various properties files?
Well ....
There's no need to have it as "public static String", but it make things
easier to garantee the uniqueness of a key. I'm don't know what happens
when having a key twice in a properties file. Do you get an error? Is
the first/latest matching taken?
But I see your fear to overload the code with public static variables.
That's why I put this for discussion.
Regards
Felix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktd9oIACgkQ2lZVCB08qHHgIACfaOvPW/D2bdh5x387W32xe95l
l4IAoMsXb9r1Y2aZetWN55Z94o2oDPX8
=4Ktm
-----END PGP SIGNATURE-----
Re: [ApacheDS] I18n
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Felix,
On 25 janv. 2010, at 17:36, Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> For translation of non error message we have 2 possibilites (because no
>> error code is needed):
>> a) Use the same method as for the error codes and have a MSG_xxx key for
>> each message
>> b) Use inline messages (see also [1])). Doing so the inline messages are
>> used as keys if existing in the i18n-properties file. As translators
>> need to know which inlines can be used as keys the need to be put into
>> the default properties file (but commented) for having a list of
>> available keys
>>
>> What can be the preferable way?
>>
>>> My preference goes to the second solution as I believe it's the same process we're using for Studio.
>>> In Studio, we're also using the class name (where the message comes from) as prefix for the keys which makes it even easier to match strings in the properties file.
>
> Using FQCN as prefix will make it impossible to avoid duplicated
> translations.
You mean, when the exact same message is used by two separate classes?
If yes, in that case, you're right, a global key without any prefix would be more appropriate.
One more question about possibility "a": Does this possibility mean that for each message a "public static String" would be created for the key in a class or interface, as well as the same key (with the translated value) in the various properties files?
Thanks,
Pierre-Arnaud
Re: [ApacheDS] I18n
Posted by Felix Knecht <fe...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> For translation of non error message we have 2 possibilites (because no
> error code is needed):
> a) Use the same method as for the error codes and have a MSG_xxx key for
> each message
> b) Use inline messages (see also [1])). Doing so the inline messages are
> used as keys if existing in the i18n-properties file. As translators
> need to know which inlines can be used as keys the need to be put into
> the default properties file (but commented) for having a list of
> available keys
>
> What can be the preferable way?
>
>> My preference goes to the second solution as I believe it's the same process we're using for Studio.
>> In Studio, we're also using the class name (where the message comes from) as prefix for the keys which makes it even easier to match strings in the properties file.
Using FQCN as prefix will make it impossible to avoid duplicated
translations.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktdyKIACgkQ2lZVCB08qHF11wCgmSfvJV4KHbyXI8JKfPFfPDL6
4HQAn0ZqC8glRyY3p4baNX/NQiRJJRq/
=s/E6
-----END PGP SIGNATURE-----
Re: [ApacheDS] I18n
Posted by Stefan Seelmann <se...@apache.org>.
Hi,
>> For translation of non error message we have 2 possibilites (because no
>> error code is needed):
>> a) Use the same method as for the error codes and have a MSG_xxx key for
>> each message
>> b) Use inline messages (see also [1])). Doing so the inline messages are
>> used as keys if existing in the i18n-properties file. As translators
>> need to know which inlines can be used as keys the need to be put into
>> the default properties file (but commented) for having a list of
>> available keys
>>
>> What can be the preferable way?
>
> My preference goes to the second solution as I believe it's the same process we're using for Studio.
> In Studio, we're also using the class name (where the message comes from) as prefix for the keys which makes it even easier to match strings in the properties file.
The advantage of "b" are the semantic keys which is IMO easier to handle
than the message code keys.
But I'd vote for "a" because its the same method as for error codes and
translators don't have to deal with different file formats.
Kind Regards,
Stefan
Re: [ApacheDS] I18n
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Felix,
On 24 janv. 2010, at 16:08, Felix Knecht wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Finally I did it. Most of the error messages are now ready for i18n (and
> translations). I hope that all messages have been replaced correctly and
> that still the same error message is shown in case, but I don't know how
> I could test this.
> Duplicates have been replaced and commented where available. I leave the
> commented duplicates in the code and properties-file. This way obvious,
> which ERR_xxx can be used when adding new error messages.
Congrats!
That's a really hard work.
> "mvn clean install" is passing well
> "mvn clean install -Dintegration":
> - JDK1.6 is hanging in StockServerISuite test case
"mvn clean install" has first hang on "org.apache.directory.shared.client.api.operations.ClientAbandonRequestTest" (LDAP API unit test project),
and then failed 2 times on "testPagedSearchTest3(org.apache.directory.server.operations.search.PagedSearchIT)" (ApacheDS Server Integration project). :(
So, I was not able to build it...
> - JDK1.5 fails with error [2]
(I haven't tested it on JDK 1.5).
> For translation of non error message we have 2 possibilites (because no
> error code is needed):
> a) Use the same method as for the error codes and have a MSG_xxx key for
> each message
> b) Use inline messages (see also [1])). Doing so the inline messages are
> used as keys if existing in the i18n-properties file. As translators
> need to know which inlines can be used as keys the need to be put into
> the default properties file (but commented) for having a list of
> available keys
>
> What can be the preferable way?
My preference goes to the second solution as I believe it's the same process we're using for Studio.
In Studio, we're also using the class name (where the message comes from) as prefix for the keys which makes it even easier to match strings in the properties file.
Regards,
Pierre-Arnaud
>
> Regards
> Felix
>
> [1]
> i18n/src/test/java/org/apache/directory/server/i18n/InlineMessageTest.java
>
> [2] (more to follow with same error
> "java.lang.UnsupportedClassVersionError: Bad version number in .class"
>
> -
> -------------------------------------------------------------------------------
> Test set: org.apache.directory.server.core.suites.SchemaISuite
> -
> -------------------------------------------------------------------------------
> Tests run: 191, Failures: 0, Errors: 6, Skipped: 96, Time elapsed:
> 16.518 sec <<< FAILURE!
> testAddComparatorWithByteCodeToEnabledSchema(org.apache.directory.server.core.schema.MetaComparatorHandlerIT)
> Time elapsed: 0.005 sec <<< ERROR!
> org.apache.directory.server.core.interceptor.InterceptorException:
> ERR_333 Unexpected exception. [Root exception is
> java.lang.UnsupportedClassVersionError: Bad version number in .class file]
> at
> org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1463)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain.access$700(InterceptorChain.java:71)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1205)
> at
> org.apache.directory.server.core.journal.JournalInterceptor.add(JournalInterceptor.java:129)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
> at
> org.apache.directory.server.core.trigger.TriggerInterceptor.add(TriggerInterceptor.java:284)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
> at
> org.apache.directory.server.core.event.EventInterceptor.add(EventInterceptor.java:152)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
> at
> org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.add(CollectiveAttributeInterceptor.java:354)
> at
> org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAktcYlcACgkQ2lZVCB08qHEqRQCgpwFEGTowgFMgvEyzA/JScROG
> nBMAoIuvLXFZs99dghWm4FTnBwsdKP75
> =GnCr
> -----END PGP SIGNATURE-----
Re: [ApacheDS] I18n
Posted by Felix Knecht <fe...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Finally I did it. Most of the error messages are now ready for i18n (and
translations). I hope that all messages have been replaced correctly and
that still the same error message is shown in case, but I don't know how
I could test this.
Duplicates have been replaced and commented where available. I leave the
commented duplicates in the code and properties-file. This way obvious,
which ERR_xxx can be used when adding new error messages.
"mvn clean install" is passing well
"mvn clean install -Dintegration":
- JDK1.6 is hanging in StockServerISuite test case
- JDK1.5 fails with error [2]
For translation of non error message we have 2 possibilites (because no
error code is needed):
a) Use the same method as for the error codes and have a MSG_xxx key for
each message
b) Use inline messages (see also [1])). Doing so the inline messages are
used as keys if existing in the i18n-properties file. As translators
need to know which inlines can be used as keys the need to be put into
the default properties file (but commented) for having a list of
available keys
What can be the preferable way?
Regards
Felix
[1]
i18n/src/test/java/org/apache/directory/server/i18n/InlineMessageTest.java
[2] (more to follow with same error
"java.lang.UnsupportedClassVersionError: Bad version number in .class"
-
-------------------------------------------------------------------------------
Test set: org.apache.directory.server.core.suites.SchemaISuite
-
-------------------------------------------------------------------------------
Tests run: 191, Failures: 0, Errors: 6, Skipped: 96, Time elapsed:
16.518 sec <<< FAILURE!
testAddComparatorWithByteCodeToEnabledSchema(org.apache.directory.server.core.schema.MetaComparatorHandlerIT)
Time elapsed: 0.005 sec <<< ERROR!
org.apache.directory.server.core.interceptor.InterceptorException:
ERR_333 Unexpected exception. [Root exception is
java.lang.UnsupportedClassVersionError: Bad version number in .class file]
at
org.apache.directory.server.core.interceptor.InterceptorChain.throwInterceptorException(InterceptorChain.java:1463)
at
org.apache.directory.server.core.interceptor.InterceptorChain.access$700(InterceptorChain.java:71)
at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1205)
at
org.apache.directory.server.core.journal.JournalInterceptor.add(JournalInterceptor.java:129)
at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
at
org.apache.directory.server.core.trigger.TriggerInterceptor.add(TriggerInterceptor.java:284)
at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
at
org.apache.directory.server.core.event.EventInterceptor.add(EventInterceptor.java:152)
at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
at
org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.add(CollectiveAttributeInterceptor.java:354)
at
org.apache.directory.server.core.interceptor.InterceptorChain$Entry$1.add(InterceptorChain.java:1197)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktcYlcACgkQ2lZVCB08qHEqRQCgpwFEGTowgFMgvEyzA/JScROG
nBMAoIuvLXFZs99dghWm4FTnBwsdKP75
=GnCr
-----END PGP SIGNATURE-----