On Tue, Apr 24, 2018 at 2:41 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
> 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".
There is a secondary consideration to gettext(), there is only one language
of localization. In a multi-tenant environment like httpd, where a number of
different administrators may operate a distinct subset of the virtual hosts
or URI space, per-server error log language scope makes a lot of sense.
The gettext() API doesn't do this.
