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.
