View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000861 | 1003.1(2013)/Issue7+TC1 | Base Definitions and Headers | public | 2014-07-31 19:50 | 2014-08-22 13:25 |
| Reporter | dalias | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Resolved | Resolution | Rejected | ||
| Name | Rich Felker | ||||
| Organization | musl libc | ||||
| User Reference | |||||
| Section | locale.h | ||||
| Page Number | unknown | ||||
| Line Number | unknown | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0000861: Add interface for querying name of active locale in a given category | ||||
| Description | At present there is no interface for querying the name of the active locale for a given category. If uselocale is not in effect, setlocale(cat, 0) serves this purpose, but obviously this method is not sufficient for programs which may be using uselocale. The main motivation for obtaining the name of the active locale is to facilitate use of translated messages at the application level, where the locale name is used as a key into some kind of translation catalog (e.g. gettext style) outside of the catgets framework. In addition, when XSI conforming locale names are in use, the locale name is also useful to communicate to remote systems, e.g. for deriving an Accept-Language header for HTTP requests, in order facilitate having messages from remote sources match the active locale. | ||||
| Desired Action | Add an interface capable of reporting the active locale for a given locale category, reflecting the locale set by uselocale if one is active, and otherwise the global locale. The specifics of this interface are open-ended, but I would prefer it not be more general or more costly to implement than necessary. It need not accept LC_ALL nor should there be excessive requirements on the lifetime of the string returned. | ||||
| Tags | No tags attached. | ||||
|
|
This bug report in its present form is rejected as development of new interfaces is not within the scope of the Austin Group. As per SD6, http://www.opengroup.org/austin/docs/austin_sd6.txt, the recommended criteria for development of new interfaces to enable them to be considered for inclusion in a future revision are as follows: 1.There must be a written specification that has undergone a formal consensus based approval process and is suitable for inclusion. Parties interested in submitting new work items through one of the three organizations within the Austin Group (The Open Group, IEEE, ISO/IEC) should contact the appropriate Organizational Representative for further information and advice on how each organization handles new work items. Submissions from other organizations will also be considered. Items 2 through 4 below apply to all submissions regardless of origin. 2.There must be an implementation, preferably a reference implementation. 3.The specification must be "sponsored" by one of three organizations (The Open Group, IEEE, ISO/IEC) within the Austin Group, i.e. they would support and champion its inclusion. 4.Submitters must provide an outline plan of the editing instructions to merge the document with the Austin Group specifications, and assistance to the Austin Group editors as required to complete the merger. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-07-31 19:50 | dalias | New Issue | |
| 2014-07-31 19:50 | dalias | Name | => Rich Felker |
| 2014-07-31 19:50 | dalias | Organization | => musl libc |
| 2014-07-31 19:50 | dalias | Section | => locale.h |
| 2014-07-31 19:50 | dalias | Page Number | => unknown |
| 2014-07-31 19:50 | dalias | Line Number | => unknown |
| 2014-08-22 13:25 | ajosey | Interp Status | => --- |
| 2014-08-22 13:25 | ajosey | Note Added: 0002360 | |
| 2014-08-22 13:25 | ajosey | Status | New => Resolved |
| 2014-08-22 13:25 | ajosey | Resolution | Open => Rejected |
