You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marion et Christophe JAILLET <ch...@wanadoo.fr> on 2018/04/19 05:20:30 UTC
Re: Expanding httpd adoption internationally - POC
Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :
> On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew <ni...@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.
the po file can then be generated with things like:
xgettext server/core.c -kap_log_error:5
This could be a good starting point which does not need to refactor
everything, at the cost of some cycles and some additional memory.
>
>> In fact, it would call for a refactoring of the entire ap_log framework
>> away from printf-style format strings and vars, that’ll inevitably give rise
>> to a whole new level of awkwardness. Which seems like a very bad
>> effort-to-gain ratio. -1 to embarking on this, unless you want to
>> create a new experimental branch to play in.
> I agree this is not a trivial change. There are specific risks of corrupting
> one language's %tokens in a way that segfaults the runtime (switch any
> %d for a %s and boom.) The resulting table is absolutely a root admin's
> directive, must not be manipulated by any other than root.
>
If using gettext, there are some tools to check for that.
CJ
Re: Expanding httpd adoption internationally - POC
Posted by Eric Covener <co...@gmail.com>.
On Thu, Apr 19, 2018 at 10:24 AM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener <co...@gmail.com> wrote:
>>> If using gettext, there are some tools to check for that.
>>
>> Would be nice to put some feelers out to $bigcos to make sure we
>> choose a format they'd accomoddate [if they were otherwise willing to
>> donate a one-time translation]
>>
>
> The IBM formats do not look very promising w/o import/export.
> (and I didn't even consider how I'd get someone to pay)
Strike that, I realize now they assign proprietary identifiers to
normal formats. So if we use gettext IBM would be a candidate.
--
Eric Covener
covener@gmail.com
Re: Expanding httpd adoption internationally - POC
Posted by Eric Covener <co...@gmail.com>.
On Thu, Apr 19, 2018 at 9:38 AM, Eric Covener <co...@gmail.com> wrote:
>> If using gettext, there are some tools to check for that.
>
> Would be nice to put some feelers out to $bigcos to make sure we
> choose a format they'd accomoddate [if they were otherwise willing to
> donate a one-time translation]
>
The IBM formats do not look very promising w/o import/export.
(and I didn't even consider how I'd get someone to pay)
Re: Expanding httpd adoption internationally - POC
Posted by Eric Covener <co...@gmail.com>.
> If using gettext, there are some tools to check for that.
Would be nice to put some feelers out to $bigcos to make sure we
choose a format they'd accomoddate [if they were otherwise willing to
donate a one-time translation]
--
Eric Covener
covener@gmail.com
Re: Expanding httpd adoption internationally - POC
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Apr 24, 2018 at 2:41 AM, Rainer Jung <ra...@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
>>> <ch...@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 <ni...@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.
Re: Expanding httpd adoption internationally - POC
Posted by Rainer Jung <ra...@kippdata.de>.
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
>> <ch...@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 <ni...@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
Re: Expanding httpd adoption internationally - POC
Posted by Marion et Christophe JAILLET <ch...@wanadoo.fr>.
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
> <ch...@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 <ni...@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...)
CJ
Re: Expanding httpd adoption internationally - POC
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Apr 19, 2018 at 12:20 AM, Marion et Christophe JAILLET
<ch...@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 <ni...@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.