On 17 March 2016 at 19:31, Daniel Eggert wrote:
> What code will be used to make then _localized_?
Good question - I wondered if Obj-C foundation translated them based
on the current locale, but it doesn't. They seem to be fixed
strings.
By the way, some more strangeness I spotted in the outpu
Well the interesting part here is that it is a localized string for a status
code, so these should be a human readable output intended for display. If they
were just stringForStatusCode then I would agree they should match the RFC, but
since it is localized I think we shouldn’t try and reimpleme
What code will be used to make then _localized_?
/Daniel
> On 17 Mar 2016, at 19:15, Ian Partridge via swift-corelibs-dev
> wrote:
>
> Hi Philippe, thanks for your quick reply.
>
> The HTTP status code reason phrases are designed to be human readable.
> They are standard phrases that are easi
Hi,
A quick question about implementing this method.
Do we want the strings returned to match those returned by the
Objective-C implementation of Foundation, or follow RFC 2616?
Currently they are inconsistent, e.g. Obj-C Foundation returns "no
error" for status code 200, whereas the RFC says thi
Hi Philippe, thanks for your quick reply.
The HTTP status code reason phrases are designed to be human readable.
They are standard phrases that are easily searched for online.
The latest table is at
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
- isn't there a case for
On 17 Mar 2016, at 19:52, Ian Partridge via swift-corelibs-dev
wrote:
> I wondered if Obj-C foundation translated them based
> on the current locale, but it doesn't.
It should translate them based on the current language (not locale). The fact
that it doesn't is a bug. This seems to be yet
