In 7.6, Locale named: #'no_NO.CP1252' returned an appropriate norwegian
locale. With the new CLDR Locales in 7.7, it now returns the C locale. Changing it to 'nb_NO...' (which is correct, but nb_NO did not exist in 7.6) I get the correct one. Questions: Why return the C locale instead of raising an error,(and subduing encodings not found) making the transition to proper locales in 7.7 less in your face, and harder to debug? Why not provide mappings for the previously valid locale identifiers to their corresponding CLDR ones? Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Well, I think the goal is that if the system doesn't have a
corresponding Locale, it will fall back to basic functionality, not cause
an exception on startup due to a missing locale.
I suspect we didn't think of the case where the old system had misspelled locales, and assumed that the new locales would be a superset. At 09:10 AM 2010-02-10, Henrik Johansen wrote: In 7.6, Locale named: #'no_NO.CP1252' returned an appropriate norwegian --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Henrik Sperre Johansen
If the locale reverts to #C on startup and does not match the value set in your operating system, it is because it has been our experience that the image may fail to start otherwise. This is in fact your indication that something is wrong.
If the locale as returned by your operating system exists in the CLDR set, and is not the locale used when VisualWorks starts (as opposed to not being in the CLDR set), there could be an initialization issue such as font support that is impeding things.
With over 400 new locales and national character sets being used in our locales now, it is inevitable that some locations will show problems. For this reason the image can be reverted to the same locale behavior as in 7.6, as documented in the release notes.
The effect of locale settings on the VisualWorks system is pervasive. Many things depend on values derived therefrom, some of them less obvious than others. Unfortunately the Legacy and CLDR Locales are not designed to be used concurrently in the image.
By the way, what operating system and version are you running on? And your operating system is set to #no_NO.CP1252?
We've done a fair amount of work to survey the names of locales across modern operating systems and have found them converging on the same CLDR/ISO set, although there are variances.
We continue to work to improve our locale support, and have further refinements to come. Feedback from user experiences is extremely important to us due to the large number of use case and environment variances possible.
Les Kooyman
Cincom From: [hidden email] on behalf of Henrik Johansen Sent: Wed 2/10/2010 6:10 AM To: [hidden email] Subject: [vwnc] Locales in 7.7 In 7.6, Locale named: #'no_NO.CP1252' returned an appropriate norwegian _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Den 10.02.2010 18:03, skrev Kooyman, Les:
I'm experienced this on Windows 7. Doing Locale current yields #'nb_NO.Windows-1252'. The reason for the code doing Locale named: #no_NO.CP1252 was needing to read norwegian-formatted numbers from strings, I took the quick and dirty way out by inspecting Locale.LocaleDictionary in 7.6 (or 7.5, can't remember), found the key for norwegian, which was #no_NO.CP1252 (still is), grabbed the locale, then used its NumberConverter's readNumberFrom:type:. (Which lead to some rather strange results using those imported numbers in 7.7, all without an error, yay) The #no_NO.CP1252 entry does not exist in LocaleLocalizationComponent.LocaleDictionary. My 2c, since getLocale is private (named: is not...), it might be better with an error-handling block in named: for the CLDR-lookup, logging an invalid CLDR-locale and checking in Locale.LocaleDictionary before setting the composite to #C/ASCII if if can't be found there either. Cheers, Henry _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Henrik Sperre Johansen
Hi,
I had a related problem to changing Locales in 7.7. According to the documentation (PDF), I should be able to change the locale like this: Locale set: #nl_NL However, this causes an exception (shouldNotImplement) and may be related to the condition Locale isCLDR being true. My current Locale says: a CompositeLocale named: #'C.MACINTOSH' Now, I use the following to change the current Locale: Locale current: (Locale named: #nl_NL) ^ Ernest _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
oops, sorry. old news
^Ernest _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Kooyman, Les
When
using the Locales, VW7.7 sets its default locale each time it is
started.
A once
set locale is not stored.
In my
case the method platformLocaleAndEncoding returns:
'C.ANSI_X3.4-1968'
The
encoding part (ANSI...) is not known by VW7.7, thus it sets its encoding to
US-ASCII
as default. This is a bad choice, it does not allow (e.g.) to output the VW trademark, which
I print on stdout (Linux) each time a user starts the image.
I had
to change the default from US-ASCII to ISO8859-1.
Karl
__________________________________________________________
Important Note: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
It may be a "bad" choice (particularly in your environment), but it's an understandable one.
From Wikipedia:
A June 1992 RFC[32] and the Internet Assigned Numbers Authority registry of character sets recognize the following case-insensitive aliases for ASCII as suitable for use on the Internet:
* ANSI_X3.4-1968 (canonical name)
* iso-ir-6 * ANSI_X3.4-1986 * ISO_646.irv:1991 * ASCII (with ASCII-7 and ASCII-8 variants) * ISO646-US * US-ASCII (preferred MIME name)[8] * us * IBM367 * cp367 * csASCII The default encoding of US-ASCII was selected with the above standards in mind.
Les Kooyman
Cincom
From: [hidden email] on behalf of BREITH Karl-Albert FDWN5-G (AREVA NP GmbH)
Sent: Wed 2/10/2010 11:39 PM To: [hidden email] Subject: Re: [vwnc] Locales in 7.7 When using the Locales, VW7.7 sets its default locale each time it is started.
A once set locale is not stored.
In my case the method platformLocaleAndEncoding returns:
'C.ANSI_X3.4-1968'
The encoding part (ANSI...) is not known by VW7.7, thus it sets its encoding to US-ASCII
as default. This is a bad choice, it does not allow (e.g.) to output the VW trademark, which I print on stdout (Linux) each time a user starts the image.
I had to change the default from US-ASCII to ISO8859-1.
Karl
__________________________________________________________ Important Note: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by BREITH Karl-Albert (AREVA)
Well, as Les points out, ANSI_X3.4-1968 is a synonym for
ASCII. So the underlying problem seems to be that the primitive that is
asking your system for its locale is answering with ASCII. Which is the
default for the C locale. So the question is why is it coming back with
the information that your system is in the C locale?
At 02:39 AM 2010-02-11, BREITH Karl-Albert FDWN5-G (AREVA NP GmbH) wrote: Content-class: urn:content-classes:messageWhen using the Locales, VW7.7 sets its default locale each time it is started. A once set locale is not stored. In my case the method platformLocaleAndEncoding returns: 'C.ANSI_X3.4-1968' The encoding part (ANSI...) is not known by VW7.7, thus it sets its encoding to US-ASCII as default. This is a bad choice, it does not allow (e.g.) to output the VW trademark, which I print on stdout (Linux) each time a user starts the image. I had to change the default from US-ASCII to ISO8859-1. Karl __________________________________________________________ Karl Breith AREVA NP GmbH FDWN-G Postfach 1109 91001 Erlangen Phone: +49 (0) 9131 900 95544 Fax: +49 (0) 9131 900 94081 mail to: [hidden email] An AREVA and Siemens company Vorsitzender des Aufsichtsrats: Olivier Wantz - Geschäftsführer: Ulrich Gräber, Rüdiger Steuerlein Sitz der Gesellschaft: Erlangen - Registergericht: Fürth, HRB 7817 - www.areva-np.com - Umsatzsteuer-ID: DE 206407096 Supervisory Board Chairman: Olivier Wantz - Managing Directors: Ulrich Gräber, Rüdiger Steuerlein Company Seat: Erlangen - Commercial Registries Fürth, HRB 7817 - www.areva-np.com - VAT ID code: DE 206407096 Wichtiger Hinweis: Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse bzw. sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. Important Note: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
As discussed a day or so ago, when you find your locale set to #C unexpectedly, it usually indicates some failure to start up the image with the locale as reported from the operating system. The specific failure could be a font issue (especially on *NIX systems), encoding issue, lack of locale support loaded in the os or otherwise broken, or any number of other things.
This is usually where we ask what 'locale' returns on your *NIX system. From: [hidden email] on behalf of Alan Knight Sent: Thu 2/11/2010 11:52 AM To: BREITH Karl-Albert FDWN5-G (AREVA NP GmbH); [hidden email] Subject: Re: [vwnc] Locales in 7.7 Well, as Les points out, ANSI_X3.4-1968 is a synonym for ASCII. So the underlying problem seems to be that the primitive that is asking your system for its locale is answering with ASCII. Which is the default for the C locale. So the question is why is it coming back with the information that your system is in the C locale? At 02:39 AM 2010-02-11, BREITH Karl-Albert FDWN5-G (AREVA NP GmbH) wrote: Content-class: urn:content-classes:messageWhen using the Locales, VW7.7 sets its default locale each time it is started. A once set locale is not stored. In my case the method platformLocaleAndEncoding returns: 'C.ANSI_X3.4-1968' The encoding part (ANSI...) is not known by VW7.7, thus it sets its encoding to US-ASCII as default. This is a bad choice, it does not allow (e.g.) to output the VW trademark, which I print on stdout (Linux) each time a user starts the image. I had to change the default from US-ASCII to ISO8859-1. Karl __________________________________________________________ Karl Breith AREVA NP GmbH FDWN-G Postfach 1109 91001 Erlangen Phone: +49 (0) 9131 900 95544 Fax: +49 (0) 9131 900 94081 mail to: [hidden email] An AREVA and Siemens company Vorsitzender des Aufsichtsrats: Olivier Wantz - Geschäftsführer: Ulrich Gräber, Rüdiger Steuerlein Sitz der Gesellschaft: Erlangen - Registergericht: Fürth, HRB 7817 - www.areva-np.com - Umsatzsteuer-ID: DE 206407096 Supervisory Board Chairman: Olivier Wantz - Managing Directors: Ulrich Gräber, Rüdiger Steuerlein Company Seat: Erlangen - Commercial Registries Fürth, HRB 7817 - www.areva-np.com - VAT ID code: DE 206407096 Wichtiger Hinweis: Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse bzw. sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank. Important Note: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |