bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bugs #9403] GNUstep does not assume an NSLanguage if one is not set in


From: Richard Frith-Macdonald
Subject: [bugs #9403] GNUstep does not assume an NSLanguage if one is not set in the defaults
Date: Mon, 21 Jun 2004 03:58:30 -0400
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #9403] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Mon 06/21/2004 at 07:58 (GMT)

------------------ Additional Follow-up Comments ----------------------------
Please coud you clarify the nature of the bug.

Are you saying that the NSLanguages user default is not being set in some 
circumstances?  If so, are you able to provide instructions to reproduce this?

The '%r' you are seeing does not appear to be a 'legal' format.  If you look at 
the Cocoa documentation for 'descriptionWithCalendarFormat:'  it refers you to 
a short section on 'Setting the Format for Dates', which in turn refers you to 
'Date Formatters', which is described as 'a complete description of the syntax 
of date format strings', ad this does not include '%r'

However, GNUstep has an extension to map '%r' to be '%I:%M:%S %p' at the point 
where a date is created... but this mapping is independant of the NSLanguages 
default.
I guess Cocoa might have a similar undocumented feature.  (or even documented 
in some other conflicting part of the docmentation).

However, there is a question of where the '%r' is coming from...
Since GNUstep maps it when a date is created, the only thing I cas think is 
that it's in a format set into a date using the setFormat: method.
Perhaps it comes from GMUmail ... in which case there would be a bug there, but 
I think it's at least as likely that GNUstep is picking it up from the locale 
information provided by the operating system.  If this is the case, then the 
bug is in mapping the O/S locale information to OpenStep/Cocoa locale 
information.







/**************************************************************************/
[bugs #9403] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=9403>
Project: GNUstep
Submitted by: Alex Perez
On: Mon 06/21/2004 at 02:20

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Change Request
Resolution:  None
Assigned to:  CaS
Status:  Open


Summary:  GNUstep does not assume an NSLanguage if one is not set in the 
defaults

Original Submission:  This problem, which has existed for at least one year and 
two months, was first addressed by Rene Berber and Robert Burns in  an e-mail 
correspondence on Discuss-GNUstep on April 28, 2003. Adam's e-mail reply, 
stating clearly that this is a bug, followed soon after and can be viewed at 
http://lists.gnu.org/archive/html/discuss-gnustep/2003-04/msg00441.html

Essentially, the problem I was experiencing was that timestamps in GNUMail were 
not displaying properly. Instead of the time, I see %r. After discussing this 
publically on the GNUstep IRC channel, Ludovic and Rob Burns told me what the 
"solution" was, which was to set NSLanguages to anything (in my case English). 
The bug is that English (or /something/) should be assumed if NSLanguages is 
not set. This affects every single person who uses GNUMail, since the 
probability is extremely high that they have not set their NSLanguages default.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Mon 06/21/2004 at 07:58       By: CaS
Please coud you clarify the nature of the bug.

Are you saying that the NSLanguages user default is not being set in some 
circumstances?  If so, are you able to provide instructions to reproduce this?

The '%r' you are seeing does not appear to be a 'legal' format.  If you look at 
the Cocoa documentation for 'descriptionWithCalendarFormat:'  it refers you to 
a short section on 'Setting the Format for Dates', which in turn refers you to 
'Date Formatters', which is described as 'a complete description of the syntax 
of date format strings', ad this does not include '%r'

However, GNUstep has an extension to map '%r' to be '%I:%M:%S %p' at the point 
where a date is created... but this mapping is independant of the NSLanguages 
default.
I guess Cocoa might have a similar undocumented feature.  (or even documented 
in some other conflicting part of the docmentation).

However, there is a question of where the '%r' is coming from...
Since GNUstep maps it when a date is created, the only thing I cas think is 
that it's in a format set into a date using the setFormat: method.
Perhaps it comes from GMUmail ... in which case there would be a bug there, but 
I think it's at least as likely that GNUstep is picking it up from the locale 
information provided by the operating system.  If this is the case, then the 
bug is in mapping the O/S locale information to OpenStep/Cocoa locale 
information.













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=9403>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]