IMHO the main issue here is backward compatibility. What should I do with
existing resources, e.g. packaged inside a jar file, that were not created
on UTF-8 format? I wouldn't mind UTF-8 been an option if this could be
configured setting some property at application level... which by default
is ISO 8859-1. Right now I do have other resources, that are NOT read via
wicket default machinery, which has to be on  ISO 8859-1 and I would not
like to have to keep in mind this distinction...
Best,

Ernesto

On Mon, Sep 28, 2009 at 3:44 PM, Robin Sander <[email protected]> wrote:

>
> Yeah, but I have to second Martin, the default encoding is also "ironed
> into my brain"... :-)
> And the OS default isn't a better choice since the default language of your
> application would
> depend on the OS environment and not on your app's or at least app-server's
> configuration.
> But that's a different discussion. (american people and i18n.... :-))
> Why don't stick to the old default encoding almost everone assumes (e.g.
> Eclipse too)
> and provide a configuration option in Application?
>
>
>
> On Sep 28, 2009, at 15:27, Johan Compagner wrote:
>
>  that was then really a stupid decision of sun..
>> If it is not even the os default (so text editor default encoding) why
>> then
>> choose one that doesnt map everything?
>>
>> On Mon, Sep 28, 2009 at 15:18, Martin Funk <[email protected]
>> >wrote:
>>
>>  Within the last 10 years SUN, so successfully, ironed into my brain that
>>> properties are ISO 8859-1, I wouldn't even dare to thinkt it could be
>>> different.
>>>
>>> see also:
>>> http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html
>>>
>>> mf
>>>
>>> 2009/9/28 Juergen Donnerstag <[email protected]>
>>>
>>>  I think SUNs default is the char encoding configured with the OS or
>>>> env vars. If you don't explicitly provide a char encoding, that is
>>>> what is used. I don't think we should assume ISO 8859-1 or any other
>>>> to be the default, but use what is configured with the OS/env.
>>>>
>>>> -Juergen
>>>>
>>>> On Mon, Sep 28, 2009 at 1:49 PM, Robin Sander <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>> I think the default should remain ISO 8859-1 because otherwise 1.4.2
>>>>> wouldn't be
>>>>> backward compatible.
>>>>> And isn't the Java default for property files ISO 8859-1so any deveoper
>>>>>
>>>> and
>>>>
>>>>> most IDEs
>>>>> would assume this encoding?
>>>>>
>>>>> robin.
>>>>>
>>>>>
>>>>> On Sep 28, 2009, at 11:42, Johan Compagner wrote:
>>>>>
>>>>>  -1 then yes
>>>>>> that shouldnt be hardcoded but a property in our settings.
>>>>>>
>>>>>>
>>>>>> On Mon, Sep 28, 2009 at 11:02, Ernesto Reinaldo Barreiro
>>>>>> <[email protected]
>>>>>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>
>>>>>>  [ X] No, don't release it and here is why...
>>>>>>>>
>>>>>>>>
>>>>>>> After upgrading to 1.4.2 all my ISO-8859-1 encoded property files
>>>>>>>
>>>>>> fail
>>>
>>>> to
>>>>
>>>>> work. I haven't look into it in detail but I guess this is related to
>>>>>>> * [WICKET-2451] - Add ability to load UTF-8 encoded properties not
>>>>>>> in XML format.
>>>>>>>
>>>>>>>
>>>>>>> I know I shouldn't be using ISO-8859-1... but right now I have a
>>>>>>>
>>>>>> bunch
>>>
>>>> of
>>>>
>>>>> those properties files. Is there an easy way to get around this?....
>>>>>>> After
>>>>>>> looking into changes I see the line (379)....
>>>>>>>
>>>>>>> Reader reader = new InputStreamReader(is, "UTF-8");
>>>>>>>
>>>>>>> Shouldn't this be cofingurable somehow?
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Ernesto
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 28, 2009 at 2:33 AM, Igor Vaynberg <
>>>>>>>
>>>>>> [email protected]
>>>>
>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>
>>>>>>>  all votes are more then welcome.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Sun, Sep 27, 2009 at 5:20 PM, Sam Stainsby
>>>>>>>> <[email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Are non-binding votes preferred or discouraged here? If the former,
>>>>>>>>>
>>>>>>>>
>>>>>>> then
>>>>>>>
>>>>>>>>
>>>>>>>>> after some testing with my projects:
>>>>>>>>>
>>>>>>>>> (nonbinding)
>>>>>>>>> [X] Yes release
>>>>>>>>> [ ] No, don't release it and here is why...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>

Reply via email to