On Wed, Apr 18, 2018 at 1:53 PM, Marion et Christophe JAILLET
<christophe.jail...@wanadoo.fr> wrote:
> Le 18/04/2018 à 20:00, William A Rowe Jr a écrit :
>>
>> Localizing our error messages alone would go a long ways to being
>> friendly to non-english speaking administrators. If we don't want to
>> bother, we can expect for our software to be further marginalized.
>
> you mean something like instrumenting our logging functions and use, for
> example, gettext as a translation mechanism?
>
> As an example on 1 file, with one logging function, something like:
>    xgettext server/core.c -kap_log_error:5 -o -
> With this example, APLOGNO() are swallowed, because xgettext is not aware of
> the stringizing done in APLOGNO(), but we could try to find a way to deal
> with it.

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.

Load this all in at startup as a hash based on the error language
requested by-vhost. So the es.example.com vhost might deliver
a host error log populated with Spanish, while the primary www.
host and global error log are in other languages. Index the various
hash string tables by language code to prevent any duplicates from
being loaded.

This makes the individual allocations even more critical, as we have
an entire set of %s %d tokens listed in that table. Adding an extra %d
element would call for a new APLOGNO() allocation.

At that point, the entire table can be programmatically translated
(somewhat goofy results) and then refined with sensible text.

The more challenging aspect are the number of "running" "stopped"
"restarting" sorts of %s text patterns which aught to also be
translated. They fall in the wrong position of some sentences, so
for a handful of these, replacing them with three distinct error log
messages might be the easier way to proceed. Otherwise, we
could have some secondary translation table for those word:word
entities, probably not associated to any specific APLOGNO.

Reply via email to