Re: [PATCH 2/3] i18n: Only extract comments marked by special tag

[Jiang Xin <worldhello.net@gmail.com>]

2014-04-18 2:08 GMT+08:00 Junio C Hamano <gitster@pobox.com>:
> Jiang Xin <worldhello.net@gmail.com> writes:
>
>> When extract l10n messages, we use "--add-comments" option to keep
>> comments right above the l10n messages for references.  But sometimes
>> irrelevant comments are also extracted.  For example in the following
>> code block, the comment in line 2 will be extracted as comment for the
>> l10n message in line 3, but obviously it's wrong.
>>
>>         { OPTION_CALLBACK, 0, "ignore-removal", &addremove_explicit,
>>           NULL /* takes no arguments */,
>>           N_("ignore paths removed in the working tree (same as
>>           --no-all)"),
>>           PARSE_OPT_NOARG, ignore_removal_cb },
>>
>> Since almost all comments for l10n translators are marked with the same
>> prefix (tag): "TRANSLATORS:", it's safe to only extract comments with
>> this special tag.  I.E. it's better to call xgettext as:
>>
>>         xgettext --add-comments=TRANSLATORS: ...
>>
>> Also tweaks the multi-line comment in "init-db.c", to make it start with
>> the proper tag, not "* TRANSLATORS:" (which has a star before the tag).
>
> Hmph.
>
> I am not very happy with this change, as it would force us to
> special case "Translators" comment to follow a non-standard
> multi-line comment formatting convention.  Is there a way to tell
> xgettext to accept both of these forms?
>
>         /* TRANSLATORS: this is a short comment to help you */
>         _("foo bar");
>
>         /*
>          * TRANSLATORS: this comment is to help you, but it is
>          * a lot longer to fit on just a single line.
>          */
>         _("bar baz");
>

We can not provide multiple `--add-comments=TAG` options to xgettext,
because xgettext holds the tag in one string, not in a list:

        /* Tag used in comment of prevailing domain.  */
        static char *comment_tag;

So if we won't change our multi-line comments for translators, must
hack gettext in some ways.

There maybe 3 ways to hack gettext:

1. When matching comments against TAG, using strstr not strncmp.

        2360         /* When the comment tag is seen, it drags in not
only the line
        2361            which it starts, but all remaining comment lines.  */
        2362         if (add_all_remaining_comments
        2363             || (add_all_remaining_comments =
        2364                   (comment_tag != NULL
        2365                    && strncmp (s, comment_tag, strlen
(comment_tag)) == 0)))

2. Add a extension to in-comment xgettext instructions.

    There is a undocumented feature in xgettext: User can provide
    instructions (prefixed by xgettext:) in comments, such as:

        /*
         * xgettext: fuzzy possible-c-format no-wrap
         * other comments...
         */

    But it does not help much, unless we hack xgettext to extend this
    hidden feature. I.E. Add an additional flag to support unconditionally
    reference to the commit block. Like:

        /*
         * xgettext: comments
         * TRANSLATORS: this comment is to help you, but it is
         * a lot longer to fit on just a single line.
         */
         _("bar baz");

3. Hack the parser for comments in "gettext-tools/src/x-c.c" (maybe
    function phase4_getc()) to support various multi-line comments style,
    such as:

        /*
         * TRANSLATORS: this comment is to help you, but it is
         * a lot longer to fit on just a single line.
         */

        /*
        ** TRANSLATORS: this comment is to help you, but it is
        ** a lot longer to fit on just a single line.
        */

        /********************************************************
         * TRANSLATORS: this comment is to help you, but it is  *
         * a lot longer to fit on just a single line.           *
         ********************************************************/


I CC this mail to the gettext mailing list. Full thread see:

 * http://thread.gmane.org/gmane.comp.version-control.git/246390/focus=246431

-- 
Jiang Xin