Re: [PATCH] Configurable SSL error details messages

On 05/20/2011 05:49 PM, Amos Jeffries wrote:
> On 21/05/11 09:39, Tsantilas Christos wrote:
>> This patch adds support for a translatable and customisable error detail
>> file (errors/templates/error_details.txt) The file is stored like we
>> store error page templates today.
>>
>> Inside the file, an HTTP-like format used that can be
>> later extended to other error details:

> +name: X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT
> +detail: "SSL Certficate error: certificate issuer (CA) not known: %ssl_ca_name"
> +descr: "Unable to get issuer certificate"
> +
> +name: X509_V_ERR_UNABLE_TO_GET_CRL
> +detail: "%ssl_error_descr: %ssl_subject"
> +descr: "Unable to get certificate CRL"
> +
> +name: X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE
> +detail: "%ssl_error_descr: %ssl_subject"
> +descr: "Unable to decrypt certificate's signature"
> +

> Do we really want to emulate the standard PO format with different names
> and line wrapping?

The HTTP-header-based format groups N details about a single error
together. PO format is not designed for that.

Any PO format resemblance to HTTP-header-based format used for error
details is purely coincidental. Moreover, I suspect we may add more
field names later for SSL errors and/or other detailed errors/reports so
it would be exceedingly harder to map PO fields to error details (even
your current mapping is a stretch already).

> (You will then have to also write a squid<->PO
> conversion tool before translators can do anything)

I am not a translation expert, but my understanding is that translators
should use standard PO format and translate only the user-visible error
"detail:" strings (and possibly "descr:" string but those are not
included in error pages right now, IIRC). If such a translation requires
a conversion tool for some reason, we can add that later. The focus of
this project is configuration, not translation.

If my understanding is wrong, then the time we spent discussing this
design a few days ago was wasted: I was under impression you have
explicitly approved the above design.

> PO Example:
>
> #: templates/ERR_ACCESS_DENIED+html.body.div.blockquote.p:23
> msgid "Access Denied."
> msgstr "Access Denied."
>
> #: templates/ERR_CACHE_ACCESS_DENIED+html.body.div.p:29
> msgid ""
> "Please contact the <a href=\"mailto:%w%W\">cache administrator</a> if
> you "
> msgstr ""
> "Please contact the <a href=\"mailto:%w%W\">cache administrator</a> if
> you "
>
>
> Note that:
> "#:" == "descr:"

Unlike "#:", the error detail description is not a reference to the
location of the error detail. It is a brief debugging string that can be
eventually translated, just like the poorly named "detail:" field should
be translated now.

> "msgid" == "name:"
> "msgstr" == "value:"

You need grouping of fields. The above allows to group only two unnamed
strings (with rather tightly coupled semantics), but not three fields
(or two even two fields if their names may vary and are meaningful).

> empty line delimits entries in both.
> '\' escaping supported by both.
> "" on the first line indicates multi-line values to PO. With each string
> line being individually "" wrapped.
>
> PO uses \n to indicate internal newlines within the template text if it
> must, however individual paragraphs like that are best-practice split
> into two entries.

The problem with PO is that it limits us to a two strings per error
detail (the rest is comments and translation-specific metadata, AFAICT).
We use three now and may need more.

Does this clarify? Or do you still think we are on the wrong track here?

Thank you,

Alex.
Received on Sat May 21 2011 - 01:13:46 MDT