Am 24.04.2018 um 07:20 schrieb Marion et Christophe JAILLET:
Le 24/04/2018 à 02:58, William A Rowe Jr a écrit :
On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
<christophe.jail...@wanadoo.fr> wrote:
Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <n...@apache.org> wrote:
I suspect the straightforward way to do this, in 2.6/3.0, will be
to add
an
i18n table of the error log strings extracted from and indexed by
those
APLOGNO() entries. No match? Default English message.
Please, not without an overhaul of APLOGNO to automate it a lot
better!
The time to devise your error message is when coding an original
ap_log_*error, not retrospectively once a number has been generated!
++1
This could be achieved easily by just adding in 'log_error_core()':
(+ a few lines to initialize gettext in main() + a few lines to get a
pool
in 'log_error_core()' (i.e. p below))
/* Check if we have a leading AHnnnnn: header */
if (p &&
fmt[0] == 'A' &&
fmt[1] == 'H' &&
apr_isdigit(fmt[2]) &&
apr_isdigit(fmt[3]) &&
apr_isdigit(fmt[4]) &&
apr_isdigit(fmt[5]) &&
apr_isdigit(fmt[6]) &&
fmt[7] == ':' &&
fmt[8] == ' ') {
const char *tmp;
/* Get the translation of the message itself */
tmp = gettext(&fmt[9]);
/* Rewrite the format string with the translated message */
fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
printf("tmp: %s\n", fmt);
}
That's all.
If interested by this approach, I can give a full working patch.
While we are unconcerned whether build tooling is GPL, we are very
concerned
that we retain license and copyright of that output, and that linking
system GPL
code does not alter our license.
As a GPL toolchain and call, this seems to require additional research.
If the tooling is clean and the gettext() call is not, then I could
fully support
following GPL gettext conversion file conventions in any custom code
we create.
I'm not really a license man, but as far as I understand, the gettext
library itself is LGPL, not GPL
(https://www.gnu.org/software/gettext/manual/html_node/Licenses.html). I
suppose that this is fine with the Apache license (but once again, I'm
not a license man...)
Since by
https://www.apache.org/legal/resolved.html
LGPL is a prohibited license (for releasing ASF code under that
license), I guess the following text from the same page applies:
===========================
Can Apache projects rely on components under prohibited licenses?
Apache projects cannot distribute any such components within their
releases. However, if the component is only needed for optional
features, a project can provide the user with instructions on how to
obtain and install the non-included work. Optional means that the
component is not required for standard use of the product or for the
product to achieve a desirable level of quality. The question to ask
yourself in this situation is:
"Will the majority of users want to use my product without adding
the optional components?"
===========================
More details are at
https://issues.apache.org/jira/browse/LEGAL-192
I (ANAL) think that the key point here is that downstreams that want to
distribute a binary version of the web server might need to include the
LGPL library in their distribution and at that point would no longer be
free to choose any license they want.
If the library were part of the OS of any target platform and thus would
not be need to get bundled, things might be different.
Surely logging is at the core of the web server. Whether
internationalizing logging would be really optional once we introduce it
is at least questionable. IMHO "the majority of users *do not * want to
use my product without adding the optional components".
Regards,
Rainer
