On 05/12/2018 20:40, Rémy Maucherat wrote:
> On Wed, Dec 5, 2018 at 9:17 PM Mark Thomas <ma...@apache.org> wrote:
>
>> On 05/12/2018 20:03, Rémy Maucherat wrote:
>>> On Wed, Dec 5, 2018 at 5:37 PM <r...@apache.org> wrote:
>>>
>>>> Author: remm
>>>> Date: Wed Dec 5 16:37:42 2018
>>>> New Revision: 1848225
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1848225&view=rev
>>>> Log:
>>>> Add i18n for the loader package.
>>>>
>>>> I have at least 350 more strings to add.
>>>
>>> I don't know what to do with:
>>> - the bootstrap.jar strings: nothing ?
>>
>> Refactor StringManager to JULI? It is somewhat logging related so that
>> doesn't seem completely crazy.
>>
>
> Ok, why not.
Apart from the fact it would mean touching almost every class in Tomcat?
Seriously, the more I think about it the more I like it. Move the res
package from o.a.tomcat.util.res o.a.juli.res and deprecate the old one
along with the copy in tribes. And then remove the old ones in 10.x
>>> - the "upstream" strings: dbcp, pool, bcel, fileupload
>>
>> We could 'fix' them. It would mean the code diverging further from the
>> original which will make syncing harder. Roughly how many Strings are we
>> talking about here?
>>
>
> About 200.
Hmm. DBCP2 already has simple l10n support along the lines of:
private static final ResourceBundle messages = ResourceBundle.getBundle(
Utils.class.getPackage().getName() + ".LocalStrings");
That could be extended. Every ASF committer has commit access to Commons
so I guess it could just be fixed at source. I'll volunteer to merge the
changes back into Tomcat.
Pool2 doesn't use a ResourceBundle but I don't see why it couldn't. Same
for FileUpload.
BCEL code is so far removed from Commons BCEL I'd probably just fix it
locally.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
